Hi Francenso, Maxime,
Am 27.10.25 um 11:09 schrieb Maxime Ripard:
Hi,
On Mon, Oct 27, 2025 at 12:03:00AM +0100, Francesco Valla wrote:
this patchset adds a new DRM client offering splash functionalities,
able to draw to screen:
- a colored background;
So, I like that part, and we were recently discussing about this.
The panic screen has configurable foreground/background colors. Maybe we
can harmonize these settings.
- a single-line text message, which can be set through sysfs or
directly from the kernel command line;
Put it into the kernel config.
- a very simple progress bar, which can be driven through sysfs;
Once you have options to control these settings from user space, you
should do it in user space entirely. As Maxime suggested, please improve
plymouth for anything with animation.
- a static image (optional).
Board vendors often provide an image, see /sys/firmware/acpi/bgrt/. This
is a candidate for display, or the penguin or a custom image. Please
make it configurable by Kconfig. Again, if you need policy and
heuristics for deciding what to display, you better do this in user space.
But there's no reason to have all that in the kernel, and we already
have userspace components to do so (plymouth being the main "mainstream"
one).
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.
If plymouth cannot be used by embedded systems for some reason, then you
should work on a plymouth alternative.
Agreed. With an updater running in user space, that process should also
manage the display update. No need for this in the kernel.
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.
== Implementation details ==
The design is quite simple, with a kernel thread doing the heavylifting
for the rendering part and some locking to protect interactions with it.
The splash image is loaded using the firmware framework, with the client
expecting to find a binary dump having the right dimensions (width and
height) and FOURCC format for each modeset. Given a 1920x1080 RGB888
modeset, the client will for example search for a firmware named:
drm_splash_1920x1080_RG24.raw
If the firmware cannot be loaded directly, the NOUEVENT sysfs fallback
mechanism is used to let userspace load the appropriate image.
== Testing ==
Testing was done on qemu (both with vkms and bochs drivers), on a HDMI
display connected to a Beagleplay and on a ILI9341 SPI display connected
to a i.MX93 FRDM board. All these platforms revealed different
weaknesses that were hopefully removed.
== Open points / issues ==
The reason for this being an RFC is that there are several open points:
- Support for tiled connectors should be there, but has not been
tested. Any idea on how to test it?
Did you mean tiled formats?
- I'm not entirely convinced that using the firmware framework to load
the images is the right path. The idea behind it was to re-use the
compressed firmware support, but then I discovered it is not there
for built-in firmware.
Yeah, firmware loading for this has a few issues (being tedious to setup
for when built-in being one). I think just going the fbdev penguin road
is a better choice: you provide the path, and it's embedded in the
kernel directly.
- Again on the firmware loading: CONFIG_LOADPIN would interfere with
sysfs loading.
- And again: FW_ACTION_NOUEVENT only has one user inside the kernel,
leading me to think it is de-facto deprecated. And still, uevents
for firmware loading seem frowned upon these days...
- Generating binary dumps for... basically any format is not so
straightforward. I crafted a Python tool with AI help which seems
to work quite well, but I honestly did not yet understood which is
the policy for AI-generated code inside the kernel, so it is not
included in this patch set. All client code is genuine, though.
BMP is simple enough to support so we should probably use that instead
of a custom format.
file /sys/firmware/acpi/bgrt/image
/sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 768 x 256
x 24, image size 589824, cbSize 589878, bits offset 54
That should probably be the format for now unless your firmware uses
something else natively. Code for reading a BMP file can be found in the
efifb driver. [1]
[1]
https://elixir.bootlin.com/linux/v6.17.5/source/drivers/video/fbdev/efifb.c#L24
Apart from the criticism for complexity, I do like the idea of having a
splash screen.
Best regards
Thomas
Maxime
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
