Hi,
On 3/18/20 3:38 PM, Simon Ser wrote:
Hi,
- Letting the VM-viewer window-system draw the cursor as it normally
would draw it.
Why is this important? Can't the VM viewer hide the cursor and use a sub-surface to manually draw the cursor plane configured by the guest?
Because then moving the cursor as seen by the user requires a round trip through the VM and that adds latency, esp. when the VM viewer is viewing a VM which is running somewhere else over the network.
The video output has latency anyway. Using the host cursor will make the primary plane and cursor plane desynchronized.
Also note that a subsurface is a Wayland specific solution, where as the VM-viewer may be running on X11, Windows, Mac OS, etc.
I'm sure other window systems have similar solutions. You could always blend the cursor yourself.
This would also allow the compositor running inside the VM to correctly have control over the cursor position, which is necessary for pointer constraints.
Vms basically have 2 mouse modes:
- Seamless, this works well for all apps which don't do weird things
with the cursor. This is what 99% of users want
- Grab/confine the mouse on the first click inside the VM-viewer window
and constantly warp it to the center so that it can move "endlessly" combined with drawing the VM's mouse cursor as a software sprite.
Combined with a special key combo to release the cursor and allow it to leave the VM window in case the user wants to interact with anything else on their desktop. AKA the "this user experience sucks" mode which sometimes is necessary for guests which don't support absolute input coordinates, or for special use cases.
Mode 2. can be used in case of apps inside the guest which want need to constrain the pointer to stay inside a part-of the vm-viewer window, note that the most prominent example of such apps are VM-viewer's themselves and the whole purpose of seamless mode is to not need this less then ideal user experience mode.
If you don't care about synchronization and breaking pointer constraints in the guest, yes a new KMS plane property will be required. This sure sounds like abusing the KMS interface though.
Anyways as I mentioned in the p.s. to my original mail already, this is exactly NOT the kind of feedback I'm looking for. Seamless mode exists, it has done so for at least a decade, probably a lot longer.
It works everywhere, across multiple platforms and hypervisors, except with the KMS atomic API. The need to set hotspot coordinates is not something which is up to discussion from my pov. What is up for discussion is how to extend the KMS atomic API to allow this.
That's not how it works.
I'm sorry to say that, but I don't think asking a project to support a feature just because you want that feature is a good mind set. You'll need to convince people maintaining the project that adding the feature is a good idea whether you like it or not.
A new feature is always up for discussion. Atomic KMS is missing the feature, and this can't be seen as a regression, because it never had the feature.