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

[Hans de Goede]

Hi,

On 3/19/20 4:16 PM, Pekka Paalanen wrote:
> On Thu, 19 Mar 2020 15:30:03 +0100
> Hans de Goede <hdegoede at redhat.com> wrote:

<snip>

>>> The only way to fix that is to stop Weston from putting non-cursor
>>> content on the cursor plane.
>>
>> Correct.
> 
> Is that something that should be done?
> 
> If the hotspot property also had a "disabled" value, then Weston could
> set the hotspot to disabled when it is using the cursor plane for
> non-cursor content and not lose the feature. And of course set hotspot
> correctly when it in fact is a cursor (but for what input?).

I believe cursor planes in the affected virtual gfx-cards do not
really have a mode where they can actually be used as a generic overlay
plane, certainly not in a useful manner (if anything works it will all
be software emulation), implementing a hotspot disabled mode would be
tricky and this would needs to be duplicated in all virtual-gfx cards
kms drivers.

If I understood Daniel's proposal for how to deal with this properly,
then only cursor planes which actually need them would get the new
hotspot x/y properties.  If we do that then Weston could use the
presence of the hotspot x/y properties to detect if it is dealing
with a proper hw plane which can also be used as a generic
plane; or a virtual-gfx cards cursor-plane, and then just not
bother with trying to use the plane as a generic hw plane.

Would that work?

<snip>

> I think one of the major reasons why Wayland pointer relative motion
> and confinement extensions were designed was VM- etc. viewers, and of
> course games.

ack.

>>> What if display servers stop using the cursor plane completely, because
>>> people may hit a case where a VM-viewer makes the wrong assumption about
>>> which input device is associated to which cursor plane inside the VM?
>>
>> The confine + warp trick is typically the default mode and only
>> if the guest indicates through e.g. a guest-agent process that
>> seamless mode is supported then seamless mode is enabled.
>>
>> IOW the VM is careful to not enable it when it might not work.
> 
> How would the guest-agent know? Does it check that there is literally
> only one pointer input device and that comes from the VM-viewer?
> Or does it limit seamless to white-listed display servers perhaps?

This varies between different solutions. E.g. the spice vdagent has
a desktop component which is started with a /etc/xdg/autostart/foo.desktop
file, assuming that it will work with any desktops honoring
/etc/xdg/autostart.

VirtualBox OTOH assumes it can use seamless mode as soon as
the vboxvideo driver loads inside the guest.

Regards,

Hans