Handling DRM master transitions cooperatively

[Dennis Filder]

Hans de Goede asked me to take a topic from a private discussion here.
I must also preface that I'm not a graphics person and my knowledge of
DRI/DRM is cursory at best.

I initiated the conversation with de Goede after learning that the X
server now supports being started with an open DRM file descriptor
(this was added for Keith Packard's xlease project).  I wondered if
that could be used to smoothen the Plymouth->X transition somehow and
asked de Goede if there were any such plans.  He denied, but mentioned
that a new ioctl is in the works to prevent the kernel from wiping the
contents of a frame buffer after a device is closed, and that this
would help to keep transitions smooth.

I am a bit disappointed with this being considered a desirable way of
handling that transfer of control over a shared DRM device as it shows
a lack of ambition.  Sure, it's probably easy to implement, but it
will also greatly limit how such transitions can be presented to the
user.  In practice it would mean plymouthd closing the DRM device and
exiting so that systemd can start the display manager which then
starts an X server to present the login screen.  If for that several
shared libraries have to first be loaded and relocated while the
system is under heavy load then there will be a noticeable delay
manifesting as a frozen screen.  After that the best you can hope for
is blending the still-frame over into the login screen (or whatever
comes then).  The VT-API-based switching mechanism currently en vogue
suffers from similar limitations.

If the approach to transferring control were to be changed to a scheme
that involves both donor and recipient process connecting to each
other on a unix socket and actively coordinating the transfer
(i.e. the calls to drmSetMaster and drmDropMaster) then this would
open the door to a host of possibilities.  Not only could the
transition be kept infinitesimally short since both processes are
already up, but it could also involve e.g. the recipient continuing an
animation the donor had going reusing state that is transferred as a
memfd.  This way there wouldn't be any noticeable freezes on the
display making for a far more polished, and thus impressive
experience.  It would be a feat a program alone cannot achieve on its
own.  Another option made possible would be implementing a watchdog.
If the recipient transfers e.g. file descriptors for a pipe and a
pidfd of itself, then the donor could monitor those for a
heartbeat/process termination and take back control over the device if
something goes awry (deadlock/crash) and initiate a recovery
mechanism.  With the other approach implementing such features is
simply not possible.

Making processes talk to each other and work together like this would
also be a far more accurate software representation of what is
actually going on: different subsystems passing control over a shared
device around to work towards the common goal of a good user
experience.

A bit of context: The idea underlying this came from my experience
with accessibility technology under Linux where uncoordinated fighting
over the audio device among all kinds of processes led to countless
ways in which things would break with no hope of ever fixing anything.
It instilled in me the conviction that user-facing programs are broken
if they are not written to talk to each other to coordinate access to
shared resources for the goal of rendering a good user experience, but
instead leave it to the distro maintainer/user to set things up into a
static, brittle working order.  Seeing a much-needed cultural shift
begin somewhere would be nice.  The Plymouth->X transition would lend
itself well as a starting point since many building blocks are already
there.

Regards