Hello,

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.

== 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?
  - 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.
  - 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.

== Additional notes ==

A bootsplash client was one of the TODOs for the DRM subsystem, so patch
3 removes the relative section from the list.

Curious to hear your thoughts. Thank you in advance!

Best regards,
Francesco

Signed-off-by: Francesco Valla <francesco@valla.it>
---
Francesco Valla (3):
      drm: client: add splash client
      MAINTAINERS: add entry for DRM splash client
      drm: docs: remove bootsplash from TODO

 Documentation/gpu/todo.rst                    |  17 -
 MAINTAINERS                                   |   7 +
 drivers/gpu/drm/clients/Kconfig               |  46 +-
 drivers/gpu/drm/clients/Makefile              |   1 +
 drivers/gpu/drm/clients/drm_client_internal.h |   9 +
 drivers/gpu/drm/clients/drm_client_setup.c    |   8 +
 drivers/gpu/drm/clients/drm_splash.c          | 761 ++++++++++++++++++++++++++
 7 files changed, 831 insertions(+), 18 deletions(-)
---
base-commit: 4bb1f7e19c4a1d6eeb52b80acff5ac63edd1b91d
change-id: 20251026-drm_client_splash-e10d7d663e7f

Best regards,
-- 
Francesco Valla <francesco@valla.it>

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

Hi,

On Monday, 27 October 2025 at 11:09:56 Maxime Ripard <mripard@kernel.org> wrote:
> 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).
> 

I get that for the "text message" and "progress bar" parts. I still have
some uses for them, that however may not be adherent to upstream philosophy.

> > 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.
> 

Thing is: any possible alternative would still start after userspace has
been loaded, checked (in case of secure boot, which is ubiquitous now)
and initialized. This means, at least in my usecases, several hundreds of
milliseconds after userspace start, to be summed to the panel initialization
time.

> > 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?
> 

No, AFAIU the tiled connectors are different connectors that feed different
panels, which however are part of a single logical screen. Support for this
setup is present at drm level [1], but I'm not familiar with it.

I've only found this used inside the i915 Intel driver [2].

> >   - 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.
> 

Yes, this is already working, but if large-ish images are used, the loading
time for them defeats the entire purpose of an in-kernel splash.

> >   - 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
> 


Thank you!

Regards,
Francesco


[1] https://elixir.bootlin.com/linux/v6.17.5/source/include/drm/drm_connector.h#L2253
[2] https://elixir.bootlin.com/linux/v6.17.5/source/drivers/gpu/drm/drm_connector.c#L2739

On Tue, Oct 28, 2025 at 08:58:05AM +0100, Francesco Valla wrote:
> On Monday, 27 October 2025 at 11:09:56 Maxime Ripard <mripard@kernel.org> wrote:
> > > 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.
>
> Thing is: any possible alternative would still start after userspace has
> been loaded, checked (in case of secure boot, which is ubiquitous now)
> and initialized. This means, at least in my usecases, several hundreds of
> milliseconds after userspace start, to be summed to the panel initialization
> time.

Yeah, but you have a *lot* of policies even for something as simple as a
bootsplash:

  * Do you want it on all your screens or just one, if so, which one?

  * If the bootsplash image doesn't fit the screen you chose, what
    should you do? stretch, crop, keep the same resolution? If the image
    is smaller than the screen, where do you want to put it? Top left
    corner? In the center?

  * If there's BGRT, do you want to have BGRT always, bootsplash always,
    compose the bootsplash with BGRT? If so, same questions than before.

etc.

The kernel can't answer all these questions, and can't address every
possible use case. Userspace can, and that's largely why plymouth
exists.

But If the main thing you care about is boot time, U-Boot has everything
needed to setup a bootsplash early.

> > > 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?
> > 
> 
> No, AFAIU the tiled connectors are different connectors that feed different
> panels, which however are part of a single logical screen. Support for this
> setup is present at drm level [1], but I'm not familiar with it.
> 
> I've only found this used inside the i915 Intel driver [2].

TIL, thanks.

> > >   - 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.
> > 
> 
> Yes, this is already working, but if large-ish images are used, the loading
> time for them defeats the entire purpose of an in-kernel splash.

The loading time of what exactly? If the image is in some section of the
binary, you wouldn't have to load anything.

Maxime

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)

Hi Thomas,

On Monday, 27 October 2025 at 13:35:31 Thomas Zimmermann <tzimmermann@suse.de> wrote:
> 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.
> 

Maybe, but probably the panic colors would typically be much more vibrant
than splash ones. 

> >
> >>    - 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.
> 

On this I can agree, see my reply to Maxime.

> >>    - 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.
>

I'm not under ACPI/UEFI typically, and the concept for this patch was not
developed on such system. But I'll take a look!

> > 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
> 

When I started working on the patch I was not able to find this BMP decoder,
I only found the PPM one from the bootup logo. I'll take a look here too.  


> Apart from the criticism for complexity, I do like the idea of having a 
> splash screen.
> 
> Best regards
> Thomas
> 
> >
> > Maxime
> 
> 

Thank you!

Best regards,
Francesco

On 10/27/25 7:35 AM, Thomas Zimmermann wrote:
> 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.

I'd actually argue that the static image from BGRT should be the 
preferred priority.  This can make for a nice hand off to Plymouth.

The (UEFI) BIOS already will show this image as soon as the GOP driver 
is loaded.  Bootloaders like GRUB by default will avoid showing anything 
or will overwrite with the exact same image in the same location.  This 
can let the kernel do the same, and then the moment Plymouth takes over 
it could do the same.
> 
>> 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
> 

On Mon, Oct 27, 2025 at 11:01:55AM -0500, Mario Limonciello wrote:
> On 10/27/25 7:35 AM, Thomas Zimmermann wrote:
> > > >    - 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.
> 
> I'd actually argue that the static image from BGRT should be the preferred
> priority.  This can make for a nice hand off to Plymouth.
> 
> The (UEFI) BIOS already will show this image as soon as the GOP driver is
> loaded.  Bootloaders like GRUB by default will avoid showing anything or
> will overwrite with the exact same image in the same location.  This can let
> the kernel do the same, and then the moment Plymouth takes over it could do
> the same.

And BGRT isn't typically found on embedded systems at all, so I'm not
sure it's a sensible default, let alone a priority. At most a possible
fallback.

Maxime

On 10/27/25 11:28 AM, Maxime Ripard wrote:
> On Mon, Oct 27, 2025 at 11:01:55AM -0500, Mario Limonciello wrote:
>> On 10/27/25 7:35 AM, Thomas Zimmermann wrote:
>>>>>     - 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.
>>
>> I'd actually argue that the static image from BGRT should be the preferred
>> priority.  This can make for a nice hand off to Plymouth.
>>
>> The (UEFI) BIOS already will show this image as soon as the GOP driver is
>> loaded.  Bootloaders like GRUB by default will avoid showing anything or
>> will overwrite with the exact same image in the same location.  This can let
>> the kernel do the same, and then the moment Plymouth takes over it could do
>> the same.
> 
> And BGRT isn't typically found on embedded systems at all, so I'm not
> sure it's a sensible default, let alone a priority. At most a possible

There are certainly embedded machines using UEFI and that have a BGRT.

How about "Sensible default the top of the priority list if it exists"

Just like Plymouth will start out with graphical splash and fallback to 
text if problems.

On Mon, Oct 27, 2025 at 11:31:06AM -0500, Mario Limonciello wrote:
> On 10/27/25 11:28 AM, Maxime Ripard wrote:
> > On Mon, Oct 27, 2025 at 11:01:55AM -0500, Mario Limonciello wrote:
> > > On 10/27/25 7:35 AM, Thomas Zimmermann wrote:
> > > > > >     - 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.
> > > 
> > > I'd actually argue that the static image from BGRT should be the preferred
> > > priority.  This can make for a nice hand off to Plymouth.
> > > 
> > > The (UEFI) BIOS already will show this image as soon as the GOP driver is
> > > loaded.  Bootloaders like GRUB by default will avoid showing anything or
> > > will overwrite with the exact same image in the same location.  This can let
> > > the kernel do the same, and then the moment Plymouth takes over it could do
> > > the same.
> > 
> > And BGRT isn't typically found on embedded systems at all, so I'm not
> > sure it's a sensible default, let alone a priority. At most a possible
> 
> There are certainly embedded machines using UEFI and that have a BGRT.

Yes, indeed, hence the "typically".

> How about "Sensible default the top of the priority list if it exists"

How about we don't tell contributors what their priorities must be?

Maxime

Hi,

On Monday, 27 October 2025 at 18:19:12 Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Oct 27, 2025 at 11:31:06AM -0500, Mario Limonciello wrote:
> > On 10/27/25 11:28 AM, Maxime Ripard wrote:
> > > On Mon, Oct 27, 2025 at 11:01:55AM -0500, Mario Limonciello wrote:
> > > > On 10/27/25 7:35 AM, Thomas Zimmermann wrote:
> > > > > > >     - 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.
> > > > 
> > > > I'd actually argue that the static image from BGRT should be the preferred
> > > > priority.  This can make for a nice hand off to Plymouth.
> > > > 
> > > > The (UEFI) BIOS already will show this image as soon as the GOP driver is
> > > > loaded.  Bootloaders like GRUB by default will avoid showing anything or
> > > > will overwrite with the exact same image in the same location.  This can let
> > > > the kernel do the same, and then the moment Plymouth takes over it could do
> > > > the same.
> > > 
> > > And BGRT isn't typically found on embedded systems at all, so I'm not
> > > sure it's a sensible default, let alone a priority. At most a possible
> > 
> > There are certainly embedded machines using UEFI and that have a BGRT.
> 
> Yes, indeed, hence the "typically".
> 
> > How about "Sensible default the top of the priority list if it exists"
> 
> How about we don't tell contributors what their priorities must be?
> 
> Maxime
> 

I'm not familiar at all with BGRT, I'll study a bit about it.

A build-time configuration could then let the user select:

- a plain solid color
- a custom static image
- the penguin logo (?)
- (on UEFI systems) BGRT source



Thank you

Regards,
Francesco

On Tue, Oct 28, 2025 at 09:09:06AM +0100, Francesco Valla wrote:
> Hi,
> 
> On Monday, 27 October 2025 at 18:19:12 Maxime Ripard <mripard@kernel.org> wrote:
> > On Mon, Oct 27, 2025 at 11:31:06AM -0500, Mario Limonciello wrote:
> > > On 10/27/25 11:28 AM, Maxime Ripard wrote:
> > > > On Mon, Oct 27, 2025 at 11:01:55AM -0500, Mario Limonciello wrote:
> > > > > On 10/27/25 7:35 AM, Thomas Zimmermann wrote:
> > > > > > > >     - 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.
> > > > > 
> > > > > I'd actually argue that the static image from BGRT should be the preferred
> > > > > priority.  This can make for a nice hand off to Plymouth.
> > > > > 
> > > > > The (UEFI) BIOS already will show this image as soon as the GOP driver is
> > > > > loaded.  Bootloaders like GRUB by default will avoid showing anything or
> > > > > will overwrite with the exact same image in the same location.  This can let
> > > > > the kernel do the same, and then the moment Plymouth takes over it could do
> > > > > the same.
> > > > 
> > > > And BGRT isn't typically found on embedded systems at all, so I'm not
> > > > sure it's a sensible default, let alone a priority. At most a possible
> > > 
> > > There are certainly embedded machines using UEFI and that have a BGRT.
> > 
> > Yes, indeed, hence the "typically".
> > 
> > > How about "Sensible default the top of the priority list if it exists"
> > 
> > How about we don't tell contributors what their priorities must be?
> > 
> > Maxime
> > 
> 
> I'm not familiar at all with BGRT, I'll study a bit about it.
> 
> A build-time configuration could then let the user select:
> 
> - a plain solid color
> - a custom static image
> - the penguin logo (?)
> - (on UEFI systems) BGRT source

It wouldn't work for generic distros that would run with the same config
on systems with and without BGRT.

Again, that whole discussion around BGRT is very premature, I'd suggest
to drop it for now.

Maxime

On 10/28/25 3:09 AM, Francesco Valla wrote:
> Hi,
> 
> On Monday, 27 October 2025 at 18:19:12 Maxime Ripard <mripard@kernel.org> wrote:
>> On Mon, Oct 27, 2025 at 11:31:06AM -0500, Mario Limonciello wrote:
>>> On 10/27/25 11:28 AM, Maxime Ripard wrote:
>>>> On Mon, Oct 27, 2025 at 11:01:55AM -0500, Mario Limonciello wrote:
>>>>> On 10/27/25 7:35 AM, Thomas Zimmermann wrote:
>>>>>>>>      - 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.
>>>>>
>>>>> I'd actually argue that the static image from BGRT should be the preferred
>>>>> priority.  This can make for a nice hand off to Plymouth.
>>>>>
>>>>> The (UEFI) BIOS already will show this image as soon as the GOP driver is
>>>>> loaded.  Bootloaders like GRUB by default will avoid showing anything or
>>>>> will overwrite with the exact same image in the same location.  This can let
>>>>> the kernel do the same, and then the moment Plymouth takes over it could do
>>>>> the same.
>>>>
>>>> And BGRT isn't typically found on embedded systems at all, so I'm not
>>>> sure it's a sensible default, let alone a priority. At most a possible
>>>
>>> There are certainly embedded machines using UEFI and that have a BGRT.
>>
>> Yes, indeed, hence the "typically".
>>
>>> How about "Sensible default the top of the priority list if it exists"
>>
>> How about we don't tell contributors what their priorities must be?
>>
>> Maxime
>>
> 
> I'm not familiar at all with BGRT, I'll study a bit about it.
> 
> A build-time configuration could then let the user select:
> 
> - a plain solid color
> - a custom static image
> - the penguin logo (?)
> - (on UEFI systems) BGRT source

Thanks!

What I had in mind (which feel free to disagree - it's an RC afterall):

User can pick one of these:

CONFIG_SPLASH_IMAGE
CONFIG_SPLASH_COLOR

If user picks CONFIG_SPLASH_IMAGE then the default behavior would be 
UEFI BGRT with a fallback to a Linux penguin.

Additionally there could be a

CONFIG_SPLASH_CUSTOM_IMAGE

This would populate the path to a custom image at build time.

If user picks this then it would override both UEFI BGRT and Linux penguin.

> 
> 
> 
> Thank you
> 
> Regards,
> Francesco