[PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
ppaalanen at gmail.com
Fri Jun 10 08:56:26 UTC 2022
On Fri, 10 Jun 2022 10:41:05 +0200
Daniel Vetter <daniel at ffwll.ch> 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
> - 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.
> 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?
sounds like a good plan to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel