Message-Id: <20251027-drm_client_splash-v1-0-00698933b34a@valla.it>
Date: Mon, 27 Oct 2025 00:03:00 +0100
From: Francesco Valla <francesco@...la.it>
To: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, 
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
 Jonathan Corbet <corbet@....net>, Jocelyn Falempe <jfalempe@...hat.com>, 
 Javier Martinez Canillas <javierm@...hat.com>
Cc: Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org, 
 dri-devel@...ts.freedesktop.org, linux-doc@...r.kernel.org, 
 linux-embedded@...r.kernel.org
Subject: [PATCH RFC 0/3] Add splash DRM client

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@...la.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@...la.it>

Powered by blists - more mailing lists