On Thursday, March 19, 2020 7:18 PM, Hans de Goede <hdegoede@xxxxxxxxxx> 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). _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
