[PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS

[Zack Rusin]

On Wed, 2022-06-08 at 10:53 +0300, Pekka Paalanen wrote:
> On Tue, 7 Jun 2022 17:50:24 +0000
> Zack Rusin <zackr at vmware.com> wrote:
> 
> > On Tue, 2022-06-07 at 11:07 +0300, Pekka Paalanen wrote:
> > > On Fri, 03 Jun 2022 14:14:59 +0000
> > > Simon Ser <contact at emersion.fr> wrote:
> > >   
> > > > Hi,
> > > > 
> > > > Please, read this thread:
> > > > https://lists.freedesktop.org/archives/dri-devel/2020-March/thread.html#259615
> > > > 
> > > > It has a lot of information about the pitfalls of cursor hotspot and
> > > > other things done by VM software.
> > > > 
> > > > In particular: since the driver will ignore the KMS cursor plane
> > > > position set by user-space, I don't think it's okay to just expose
> > > > without opt-in from user-space (e.g. with a DRM_CLIENT_CAP).
> > > > 
> > > > cc wayland-devel and Pekka for user-space feedback.
> > > > 
> > > > On Thursday, June 2nd, 2022 at 17:42, Zack Rusin <zack at kde.org> wrote:
> > > >   
> > > > > - all userspace code needs to hardcore a list of drivers which require
> > > > > hotspots because there's no way to query from drm "does this driver
> > > > > require hotspot"    
> > > > 
> > > > Can you elaborate? I'm not sure I understand what you mean here.
> > > >   
> > > 
> > > Hi Zack and everyone,
> > > 
> > > I would like to try to reboot this discussion and explain where I come
> > > from. Maybe I have misunderstood something.  
> > 
> > <snip> First of all thanks for restarting the discussions. I think Gerd did a good
> > job responding to individual points, so let me take a step back and explain the big
> > picture here so we can reboot.
> > 
> > > Which root problems do you want to solve exactly?  
> > 
> > The problem that this patch set is solving is the relatively trivial problem of not
> > having a way of setting the hotspot in the atomic kms interface. When we
> > (virtualized drivers) are using the native cursor we need to know not only the image
> 
> Could you clarify what is "native cursor" here?
> I guess it is the host window system pointer's cursor?

Right, exactly. I'm a little hesitant to call it "host" because it gets tricky in
remote scenarios, where the host is some ESXi server but the local machine is the
one that's actually interacting with the guest. So it's the cursor of the machine
where the guest screen is displayed.


> > Now, where the disagreements come from is from the fact that all virtualized drivers
> > do not implement the atomic KMS cursor plane contract exactly as specified. In
> > atomic kms with universal planes the "cursor" plane can be anything so asking for
> > hotspot's for something that's not a cursor is a bit silly (but arguably so is
> > calling it a cursor plane and then complaining that people expect cursor in it).
> > 
> > So the argument is that we can't put hotspot data into atomic kms without first
> > rewriting all of the virtualized drivers cursor code to fix the underlying contract
> > violation that they all commit. That would likely be a lot easier sell if not that
> > gnome/kde don't put none cursor stuff in the cursor plane, so all this work is to
> > fix breakages that seem to affect 0 of our users (and I completely understand that
> > we'd still like all the drivers to be correct and unified in terms of their
> > behaviour, I'm just saying it's a hard sell without something that we can point to
> > and say "this fixes/improves things for our customers") 
> 
> What's the cost of making paravirtualized drivers honour the UAPI contract?
> Can't you do that on the side of implementing these new hotspot
> properties, with the little addition to allowing guest userspace to be
> explicit about whether it supports commandeering or not?

I'm reluctant here because "fixing" here seems to be a bit ephemeral as we move from
one solution to the next. I'm happy to write a patch that's adding a
DRM_CLIENT_CAP_VIRTUAL_CURSOR_AWARE flag and hiding the cursor plane in virtualized
drivers for clients that advertise DRM_CLIENT_CAP_ATOMIC but not
DRM_CLIENT_CAP_VIRTUAL_CURSOR_AWARE, but that doesn't solve Weston on virtualized
drivers.

I feel like that's a larger discussion. One that we need to have in general - it's
about standardising on behaviour of userspace with virtualized drivers, e.g. on
Weston even the most basic functionality of virtualized drivers which is resizing a
window doesn't work correctly (virtualized drivers send drm_kms_helper_hotplug_event
which sends a HOTPLUG=1 event with a changed preferred width/height but Weston
doesn't seem to resize the fb on them which results in Weston not resizing to the
new size of the window) or even considering the suggested_x and suggested_y
properties. It seems like we might need to have a wider discussion on standardising
those common issues on virtualized drivers because currently, I'm guessing, that
apart from Gnome and KDE most compositors are completely broken on virtualized
drivers.

I'd prefer not blocking fixing hotspots until all those issues are resolved so if we
can agree on what we'd like to fix before hotspots go in, that'd be great.

z