Handling DRM master transitions cooperatively

[Dennis Filder]

On Tue, Sep 07, 2021 at 05:52:41PM +0200, Sebastian Wick wrote:
> > 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.

The idea was that since you would have to have some IPC mechanism in
user space anyway to quickly effect a flicker-free transition from
Plymouth to the display manager (since, as de Goede reiterates in the
other message, both processes must have the device already open and
call drmSetMaster/drmDropMaster coordinatedly) you might just as well
look for ways how it could be designed for the benefit of everyone.
Using "implicit protocols" for things like this is usually the go-to
way, not because it's good design, but because it is easy to
implement.  But these "implicit protocols" have a tendency to greatly
limit what can be done and to not be easily adaptable once the use
cases become more complicated or refined, and thus they force
contortions on everyone eventually.

How such a protocol could look?  I don't know.  Maybe some DBus
interface for a broker/multiplexer for shared devices that would keep
track of the current DRM master and tell any process interested in
obtaining it what process to talk to.  It could then contact it either
via DBus or over a separate socket, communicate its capabilities,
negotiate the modalities for the transition and acquire the necessary
resources in the form of file descriptors passed over DBus/the socket.
Then both processes could set themselves up for the transition and
effect it, which could involve e.g. unlocking a locked mutex/semaphore
in shared memory.  Alternatively, the donor could refuse the handover,
e.g. if a screen locker is configured to prohibit release of the
device.  Complexitywise the sky would be the limit, of course, but it
needn't be this complicated from the beginning.  An initial version of
such a protocol could be held just as simple as the status quo.

As for the point raised by Paalanen that implementing something like
this would require a lot of effort I must state that, while certainly
true, many of the things I mentioned here are already implemented
somehow somewhere.  Plymouth has a control socket and protocol with
which the state of the splash screen can be controlled from the
outside to make the transition to gdm smoother.  The xlease project
apparently was designed with the intent that DRM devices should be
leased (and subleased) out to processes, and cross-process
coordination would be governed this way.  The kmscon project also had
to come up with something to govern device access since it could no
longer piggy-back on the VT-API.  systemd-logind also draws up a
framework for governance over a shared device and how to tie them to
sessions/seats (with such peculiarities that you cannot auto-spawn a
getty on tty1 since that is "reserved" for Wayland).  Then there is
the VT console, and probably lots of other little things I don't even
know about.

All this effort is already being expended, and IMO it proves the need
for some way to gracefully coordinate access to shared devices that
offers more than what can be done with current "implicit protocols".
The community should consider acknowledging this need and trying to
answer the question what such a subsystem should and should not look
like.  Once the nature of the problem is understood better
implementational questions will become easier.

Regards.