Sent out on Sunday to the Linux kernel mailing list was a proposal for a new Direct rendering Manager (DRM) client for providing “splash screen” type functionality such as for embedded systems and more. But with Plymouth in user-space already being the dominant solution here and upstream developers tending to prefer such functionality in user-space instead, its future remains uncertain with some developers already questioning the value of this proposed solution.
The “Splash” DRM client is explained in its Request For Comments patch series as:
“this patchset adds a new DRM client offering splash functionalities, able to draw to screen:
– a colored background;
– a single-line text message, which can be set through sysfs or directly from the kernel command line;
– a very simple progress bar, which can be driven through sysfs;
– a static image (optional).Once compiled inside the kernel, the client can be enabled through the command line specifying the drm_client_lib.active=splash parameter.
== Motivation ==
The motivation behind this work is to offer to embedded system developers a new path for a simple activation of the display(s) connected to their system, with the following usecases:
– bootsplash – possibly displaying even before init;
– early activation of the display pipeline, in particular whenever one component of the pipeline (e.g.: a panel) takes a non-negligible time to initialize;
– recovery systems, where the splash client can offer a simple feedback for unattended recovery tasks;
– update systems, where the splash client can offer a simple feedback for unattended update tasks.While the first seems the most obvious one, it was the second that acted as the driver, as in the past I had to implement a ugly workaround using a systemd generator to kickstart the initialization of a display and shave ~400ms of boot time.
The last 2 usecase, instead, are the reason I dropped the “boot” part from bootsplash.”
With Plymouth widely being used already for boot splash screen functionality on Linux systems, DRM Panic working out well as a recovery-type screen, etc, it remains to be seen if there will be sufficient interest by upstream developers for wanting this new code in the kernel. At the moment this new DRM client is just over 800 lines of new code.
While its upstream future remains uncertain, those wanting to learn more about this proposed Splash DRM client can find it on the mailing list.
