Atomic KMS API lacks the ability to set cursor hot-spot coordinates

[Simon Ser]

> Hi,
>
> On 3/18/20 3:38 PM, Simon Ser wrote:
> > Hi,
> >
> >> 1) 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:
>
> 1) Seamless, this works well for all apps which don't do weird things
> with the cursor. This is what 99% of users want
>
> 2) 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.