On 6/29/23 01:16, Pekka Paalanen wrote:
On Wed, 28 Jun 2023 16:26:37 +0000
Zack Rusin <zackr@xxxxxxxxxx> 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
