Handling DRM master transitions cooperatively

[Sebastian Wick]

> 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 state reset already is an implicit protocol. Another IPC mechanism
however could extend it to work the other way around: instead of
inheriting all the state and trying to transition from that to the
second client's desired state the second client would send its own
desired state back to the first (instead of applying it immediately)
which would then try to transition from its own state to the second
state (and if it can't you fall back to the implicit inherited state
protocol). However, this is only an improvement if the first client
knows how to do the transition and the second does not. All in all I
doubt that you can convince most people to add this kind of complexity
just for slightly higher chances of a good transition.

The reset state protocol on the other hand solves real problems and
gives you a good transition as long as the second client knows about the
same properties as the previous one which usually is the case for the
typical bootsplash->login manager->compositor chain.

Maybe I'm completely missing how such a protocol would work though.

> 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.
> 
> 
> Thanks,
> pq