Re: [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots

[Michael Banack <banackm@vmware.com>]

On 6/29/23 01:16, Pekka Paalanen wrote:
> On Wed, 28 Jun 2023 16:26:37 +0000
> Zack Rusin <zackr@vmware.com> wrote:
>
>> An argument could be made that crtc x/y properties should be removed on the cursor
>> plane in drivers for para-virtualized hardware and instead replaced with
>> mouse_position x/y properties that do exactly what crtc x/y properties do but make
>> it explicit what they really are on a cursor plane.
> I suppose this is needed to support the guest OS warping the cursor position
> while the viewer has a relative-motion pointer locked to it?
>
> When the pointer is not locked to the VM viewer window, the pointer
> sends absolute motion events? Which is necessary for the roundtrip
> elision that the hotspot is needed for in the first place.
>
> Btw. this is somewhat conflicting with what you wrote as the first UAPI
> doc draft. I don't see how the viewer/host could independently position
> the cursor image if the related pointer device is not also delivering
> absolute motion events in the guest. Delivering relative motion events
> would cause the guest and host opinion of pointer position to drift
> apart primarily due to different acceleration curves.

Again, I can't speak for all clients, but VMware will heuristically 
determine when to send absolute vs relative mouse events, and when to 
accelerate the cursor into the client's cursor, and when to emulate the 
cursor image on the client.

So yes, if a userspace application is moving the mouse on it's own (like 
a VNC server warping the mouse), that will today get forwarded to the 
display driver and up to the hypervisor and the client console, which 
would normally then choose to correctly draw the cursor image where the 
guest positioned it.  Only when the client believes that it is currently 
in control of the mouse will it accelerate it all the way through the 
client and send absolute input events down.

--Michael Banack