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

[Zack Rusin <zackr@vmware.com>]

On Tue, 2022-06-07 at 11:07 +0300, Pekka Paalanen wrote:
> On Fri, 03 Jun 2022 14:14:59 +0000
> Simon Ser <contact@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@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
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.

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") 

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.

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.

z