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

[Simon Ser]

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).