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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, I can speak to the virtual mouse/console half of this from the VMware-side.

I believe Zack's preparing a new set of comments here that can speak to most of your concerns, but I'll answer some of the other questions directly.

On 6/29/23 01:03, Pekka Paalanen wrote:

Is it really required that the hotspot coordinates fall inside the
cursor plane? Will the atomic commit be rejected otherwise?
Most console systems require the hotspot to get within the cursor image, but in theory it's semantically meaningful to have it extend outside the image.

VMware's clients in particular will clamp the hotspot to the dimension of the cursor image if we receive one that's out of bounds.

So I would assume the right thing to do here would be to allow it and let the clients figure out how to best handle it.


  *
  * This information is only relevant for drivers working on top
  * of para-virtualized hardware. The reason for that is that
  * the hotspot is fairly encapsulated in the system but imagine having
  * multiple windows with virtual machines running on servers
  * across the globe, as you move the mouse across the screen
  * and the cursor moves over those multiple windows you wouldn't
  * want to be sending those mouse events to those machines, so virtual
  * machine monitors implement an optimization where unless the mouse
  * is locked to the VM window (e.g. via a click) instead of propagating
  * those mouse events to those VM's they change the image of the native
  * cursor to what's inside the mouse cursor plane and do not interact
  * with the VM window until mouse is clicked in it.
Surely the mouse events are sent to those machines across the globe
regardless?

The point I believe you want to make is that in addition that, a
virtual machine viewer application independently moves the cursor image
on the viewer window to avoid the roundtrip latency across the globe
between mouse movement and cursor movement.

Why is the locking you mention relevant? Wouldn't you do this
optimization always if there is any cursor plane image set?

Or if you literally do mean that no input is sent to the VM at all
until the pointer is locked to that window, then why bother using the
guest cursor image without locking?

I suppose different viewers could do different things, so maybe it's
not necessary to go into those details. Just the idea of the viewer
independently moving the cursor image to reduce hand-eye latency is
important, right?

Yeah, the discussions of "locking" here are more implementation details of how VMware's console works, and while  there are other consoles that work this way, many of them don't.

So it's probably more confusing than helpful without some more background that the other layers here don't need to worry about.

The main idea is that the client needs to know where the VM thinks the mouse is to determine whether it /can/ safely accelerate it all the way through to the client's cursor stack.  If something else in the VM is moving the mouse around, like an additional remote connection, then the client needs to fallback to an emulated cursor on the client side for a while.

The question of which input device corresponds to which cursor plane
might be good to answer too. I presume the VM runner is configured to
expose exactly one of each, so there can be only one association?
As far as I know, all of the VM consoles are written as though they taking the place of what would the the physical monitors and input devices on a native machine.  So they assume that there is one user, sitting in front of one console, and all monitors/input devices are being used by that user.

Any more complicated multi-user/multi-cursor setup would have to be coordinated through a lot of layers (ie from the VM's userspace/kernel and then through hypervisor/client-consoles), and as far as I know nobody has tried to plumb that all the way through.  Even physical multi-user/multi-console configurations like that are rare.


Btw. for my own curiosity, what happens if there are two simultaneous
viewer instances open to the same VM/guest instance? Will they fight
over controlling the same pointer?

I can't speak for all consoles, but VMware at least uses a bunch of heuristics that typically boil down to which mouse input source has been moving the cursor most recently.

--Michael Banack



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux