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

Wed Jun 8 07:53:38 UTC 2022

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?

> and position of the cursor, we need to know which point within that cursor activates
> the click (going back to analogy from the previous email: cursor image with arrow
> point top-left and cursor image image with arrow pointing bottom-right will have
> different hotspots, likely  [0, 0] in the first case and [cursor_width,
> cursor_height] in the latter). To correctly route the mouse clicks we need to be
> aware of the hotspot coordinates. Currently even though all virtualized drivers are
> atomic userspace has to explicitly disable atomic kms for those drivers because
> mouse clicks are offset incorrectly as soon as the cursor image changes from the
> top-left pointing arrow, i.e. the hotspot isn't at [0,0]).
> 
> So we would like to be able to enable atomic kms with gnome and kde on virtualized
> drivers and to do that we need a way to pass hotspot coordinates from userspace to
> virtualized driver.
> 
> That seems to be pretty self-explanatory and, I think, we all agree that will go
> through properties like in the attached patch set.

Right.

> 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?

The deny-lists exist in guest userspace already, and they are not going
anywhere any time soon that I can see. So the delay in getting those
deny-lists side-stepped is the same delay it would take to have the
guest userspace use the new UAPI to properly say they do support
commandeering.

In your mind, how do you expect guest userspace like Mutter to drop the
deny-lists? What would make GNOME developers be willing to do that? And
why is that somehow easier or faster than a new proper UAPI to be
explicit about commandeering?

You already need patches to guest userspace to fill in the hotspot
properties, so I don't get the resistance to adding another flag to be
explicit about commandeering as well. Especially when, as you say, the
big desktops do not even try to put non-cursor images on cursor planes,
it should be trivial for them to set the flag, easier than filling in
the hotspot properties.

Then projects like Weston who would indeed need larger surgery to
support commandeering will simply not set the flag, nor program hotspot
properties, and will get correct (but with high cursor latency)
behaviour from guest KMS.

> Finally there's a discussion on how to fix it and whether virtualized drivers need
> to do funky stuff with the cursor. I'd like to first make sure we're on the same
> page and then discuss how to fix it next, so let me finish by saying why not
> "software cursor".
> 
> The easiest way to understand why we do what we do with the cursor, avoiding any
> complex and weird cases lets go back to the latency issue: the round trips to the
> guest to move the cursor are certainly noticeable when running locally, but with my
> VMware hat on, "local" is not the case that interest us, e.g. on ESXi every VM is
> accessed over a network so now we're dealing with remote round trips. When
> multiplied by slow connections and scale at which we're operating the "software
> cursors" go from "some latency" to "completely unusable". That's what I was alluding
> to in the earlier email when I said they're broken in different ways because if
> asked what would you prefer: cursor that when clicked is always incorrectly offset,
> or choppy/unusably slow cursor - you'll get different answers, depending on who you
> ask. Virtualization vendors tend to invest pretty heavily into protocols that
> improve on vnc/rdp for remote machine access and we'd like to not lose that.

Very good.

It is important to be clear about the different ways of being broken,
so that we can discuss which faults are being fixed by a proposal
rather than arguing whether the proposal fixes "the fault" or not. If
one side understands "the fault" to be one thing and the other side
thinks it's two separate things, there can never be agreement.

> All in all, what we'd like:
>  - is to be able to run at least the dominant desktops with atomic kms
> what we need:
>  - we need the hotspot data,
> what we want to avoid:
>  - fallbacks to software cursors
>  - large additions to user-space
> 
> I hope this clarifies things a bit.

Yes, it does, to me at least.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220608/45b94a98/attachment.sig>