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
