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. > - 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). 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. > 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. Maxime
signature.asc
Description: PGP signature
