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

[Simon Ser]

------- Original Message -------
On Sunday, June 5th, 2022 at 17:47, Zack Rusin <zackr at vmware.com> wrote:

> > > Also, let me point this out because it also seems to be a fundamental
> > > misunderstanding, user space implementing software cursor doesn’t fix
> > > anything. Just leaves everything broken in different ways. The reason
> > > virtualized drivers went away from software cursors is because it makes it
> > > impossible to make it work with a bunch of interesting and desirable
> > > scenarios, e.g. unity mode where the guest might have a terminal and browser
> > > open and then the virtual machine software creates windows out of those, so
> > > you don’t have the entire desktop of the guest but instead native looking
> > > windows with the apps. In that case guest has no way of knowing when the
> > > cursor leaves the window, so to make seemless cursors work you’d need to
> > > implement irc or backdoors that send that information from the host to the
> > > guest, then have virtualized drivers create some sort of uevent, to send to
> > > the userspace to let it know to hide the cursor because it actually left the
> > > window. That’s a trivial scenario and there’s a lot more with mice that are
> > > remoted themselves, guests with singular or maybe many apps exported,
> > > possibly overlapping on the host but all within a desktop in the guest, etc.
> >
> > Are you saying that the current broken behavior is better than software
> > cursors?
>
> They’re broken in very different ways. You’re asking me which bugs do
> I prefer. Ultimately the current lack of hotspots leaves mouse unusable
> but I don’t see any reason to trade that for another set of bugs instead
> of just fixing it (either via fallback to legacy or using the new hotspot
> api).

Software cursors aren't a bug. They're a fallback.

> > > > > > New user-space supports setting the hotspot prop, and is aware that it can't
> > > > > > set the cursor plane position, so the cursor plane can be exposed again when
> > > > > > the cap is enabled.
> > > > >
> > > > > But we still use cursor plane position. Hotspots are offsets from
> > > > > cursor plane positions. Both are required.
> > > >
> > > > No, VM drivers don't need and disregard the cursor position AFAIK. They
> > > > replace it with the host cursor's position.
> > >
> > > Iirc they all use it.
> >
> > What do they use it for?
> >
> > The whole point of this discussion is to be able to display the guest's cursor
> > image on the host's cursor, so that latency is reduced?
>
>
> Ah, I think I see now where the confusion is coming from. No, it’s
> definitely not. This has nothing to do with latency. By default
> position of a mouse cursor doesn’t tell us where the point that is
> actually used as an activation of a click is, e.g. a mouse cursor image
> with an arrow pointing to the top-left and a mouse cursor image pointing
> to the bottom right - both at the same position, as you can imagine it will
> become impossible to use the desktop if the click defaults to the top left,
> especially as the number of cursor images increases, you need information
> about which point within the cursor image activates the click, that’s the
> hotspot. You need to know the position of the image and you need to know
> which point within that image is responsible for actually activating the
> events.

Yeah, that's what a hotspot is.

By "the whole point of this discussion", I meant that the whole point
for VM drivers to expose a hardware cursor is to improve latency (and
provide other related features).

At any rate, I consider broken any driver which exposes a cursor plane,
then doesn't display it exactly at the CRTC_X/CRTC_Y or misbehaves if
it's missing hotspot info.