On Fri, 10 Jun 2022 10:41:05 +0200 Daniel Vetter <daniel@xxxxxxxx> 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? Hi, sounds like a good plan to me. Thanks, pq
Attachment:
pgprl7bH_NnRm.pgp
Description: OpenPGP digital signature
