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

[Hans de Goede]

Hi,

On 3/19/20 9:14 PM, Simon Ser wrote:
> On Thursday, March 19, 2020 7:18 PM, Hans de Goede <hdegoede at redhat.com> wrote:
> 
>>>>> 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?
> 
> That would need to at least be hidden behind a DRM capability, otherwise
> it would break existing user-space ignoring the hotspot props (e.g.
> current Weston).

Current Weston is already broken, fixing that is what this whole
thread is about.

The virtual gfx-cards drivers simply must now the hotspot for things to
work; and a capability is not going to help here for 2 reasons:

1) Short of disabling seamless mode there is nothing the virtual
gfx-cards drivers can do when clients do not pass the hotspot info;
and in some cases they cannot even do this as it is under control
of a userspace agent process with its own channel to the hypervisor.

2) Most existing clients which obviously do not set this to-be-introduced
capability already pass the hotspot info using the DRM_IOCTL_MODE_CURSOR2
ioctl. Disabling seamless mode when this to-be-introduced capability is
not set would cause a huge regression for all these existing clients.

Regards,

Hans