[PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
aesteve at redhat.com
Fri Jun 9 15:20:13 UTC 2023
On 6/10/22 10:59, Daniel Vetter wrote:
> On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote:
>> Hi all,
>> Kinda top post because the thread is sprawling and I think we need a
>> summary/restart. I think there's at least 3 issues here:
>> - lack of hotspot property support, which means compositors can't really
>> support hotspot with atomic. Which isn't entirely true, because you
>> totally can use atomic for the primary planes/crtcs and the legacy
>> cursor ioctls, but I understand that people might find that a bit silly :-)
>> Anyway this problme is solved by the patch set here, and I think results
>> in some nice cleanups to boot.
>> - the fact that cursors for virtual drivers are not planes, but really
>> special things. Which just breaks the universal plane kms uapi. That
>> part isn't solved, and I do agree with Simon and Pekka that we really
>> should solve this before we unleash even more compositors onto the
>> atomic paths of virtual drivers.
>> I think the simplest solution for this is:
>> 1. add a new DRM_PLANE_TYPE_VIRTUAL_CURSOR, and set that for these
>> special cursor planes on all virtual drivers
>> 2. add the new "I understand virtual cursors planes" setparam, filter
>> virtual cursor planes for userspace which doesn't set this (like we do
>> right now if userspace doesn't set the universal plane mode)
>> 3. backport the above patches to all stable kernels
>> 4. make sure the hotspot property is only set on VIRTUAL_CURSOR planes
>> and nothing else in the rebased patch series
> Simon also mentioned on irc that these special planes must not expose the
> CRTC_X/Y property, since that doesn't really do much at all. Or is our
> understanding of how this all works for commandeered cursors wrong?
>> - third issue: These special virtual display properties arent documented.
>> Aside from hotspot there's also suggested X/Y and maybe other stuff. I
>> have no idea what suggested X/Y does and what userspace should do with
>> it. I think we need a new section for virtualized drivers which:
>> - documents all the properties involved
>> - documents the new cap for enabling virtual cursor planes
>> - documents some of the key flows that compositors should implement for
>> best experience
>> - documents how exactly the user experience will degrade if compositors
>> pretend it's just a normal kms driver (maybe put that into each of the
>> special flows that a compositor ideally supports)
>> - whatever other comments and gaps I've missed, I'm sure
>> Simon/Pekka/others will chime in once the patch exists.
> Great bonus would be an igt which demonstrates these flows. With the
> interactive debug breakpoints to wait for resizing or whatever this should
> be all neatly possible.
We have been testing the v2 of this patch and it works correctly for us.
First we tested with a patched Mutter, the mouse clicks were correct,
and behavior was as expected.
But I've also added an IGT test as suggested above:
I could post the IGT patch upstream once Zack's patches land.
Hope that helps!
>> There's a bit of fixing oopsies (virtualized drivers really shouldn't have
>> enabled universal planes for their cursors) and debt (all these properties
>> predate the push to document stuff so we need to fix that), but I don't
>> think it's too much. And I think, from reading the threads, that this
>> should cover everything?
>> Anything I've missed? Or got completely wrong?
>> Cheers, Daniel
>> On Fri, Jun 03, 2022 at 02:14:59PM +0000, Simon Ser wrote:
>>> Please, read this thread:
>>> It has a lot of information about the pitfalls of cursor hotspot and
>>> other things done by VM software.
>>> In particular: since the driver will ignore the KMS cursor plane
>>> position set by user-space, I don't think it's okay to just expose
>>> without opt-in from user-space (e.g. with a DRM_CLIENT_CAP).
>>> cc wayland-devel and Pekka for user-space feedback.
>>> On Thursday, June 2nd, 2022 at 17:42, Zack Rusin <zack at kde.org> wrote:
>>>> - all userspace code needs to hardcore a list of drivers which require
>>>> hotspots because there's no way to query from drm "does this driver
>>>> require hotspot"
>>> Can you elaborate? I'm not sure I understand what you mean here.
>> Daniel Vetter
>> Software Engineer, Intel Corporation
More information about the wayland-devel