Hi,
On 3/19/20 10:07 PM, Simon Ser wrote:
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.
Compositors which don't support the hotspot prop are and will continue to break
seamless mode. Setting the prop will never be mandatory, because all user-space
today doesn't do it.
Since we need to update all user-space to add support for this prop, it would
be a good idea to recognize user-space that doesn't support it. Doing something
sensible with user-space that doesn't support the prop is up to the virtual
driver.
If we have a capability, the virtual driver could for instance not advertise a
cursor plane at all if user-space won't correctly set the hotspot anyway.
What compositors do we have around today that wouldn't want to support
setting the hotspot correctly? Do we like to keep them that way, and do
we want to encourage any new compositors to also not do this properly?
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
