Handling DRM master transitions cooperatively

[Simon Ser]

> On Tue, 07 Sep 2021 10:19:03 +0000
> Simon Ser <contact at emersion.fr> wrote:
>
> > FWIW, I've just hit a case where a compositor leaves a "rotation" KMS
> > prop set behind, then Xorg tries to startup and fails because it doesn't
> > reset this prop. So none of this is theoretical.
> >
> > I still think a "reset all KMS props to an arbitrary default value" flag
> > in drmModeAtomicCommit is the best way forward. I'm not sure a user-space
> > protocol would help too much.
>
> Hi Simon,
>
> for the "reset KMS state" problem, sure. Thanks for confirming the
> problem, too.
>
> The hand-off problem does need userspace protocol though, so that the
> two parties can negotiate what part of KMS state can be inherited by
> the receiver and who will do the animation from the first to the second
> state in case you want to avoid abrupt changes. It would also be useful
> for a cross-fade as a perhaps more flexible way than the current "leak
> an FB, let the next KMS client scrape it via ioctls and copy it so it
> can be textured from".

The KMS state can be limited to single FB on primary plane covering the whole
CRTC, no scaling, no other property set than FB_ID/CRTC_*/SRC_*.

Is it useful to make the previous client perform the animation? I don't really
understand the use-case here.

> Userspace protocol is also useful for starting the next KMS client
> first and handing off only later once it's actually running. I'm not
> sure if that is already possible with the session switching stuff, but
> I have a feeling it might be fragile or miss pieces like the next KMS
> client signalling ready before actually switching to it.

Hm, right. I'm not 100% clear if it's possible for the next client to set
everything up while the VT is not active.

It would help to make logind/seatd give a non-master DRM FD when VT-switched
away. Not sure they do it atm.