From: Maxime Ripard <mripard@kernel.org>
To: Francesco Valla <francesco@valla.it>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
Jonathan Corbet <corbet@lwn.net>,
Jocelyn Falempe <jfalempe@redhat.com>,
Javier Martinez Canillas <javierm@redhat.com>,
Sam Ravnborg <sam@ravnborg.org>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-doc@vger.kernel.org, linux-embedded@vger.kernel.org
Subject: Re: [PATCH RFC 0/3] Add splash DRM client
Date: Wed, 29 Oct 2025 09:34:53 +0100 [thread overview]
Message-ID: <k5ktlmzszlk2qzn4mteduardoda7npxyd6m5rn6avjneayoqbw@q32utxpy7lk6> (raw)
In-Reply-To: <2756316.lGaqSPkdTl@fedora.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 5171 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
prev parent reply other threads:[~2025-10-29 8:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-26 23:03 [PATCH RFC 0/3] Add splash DRM client Francesco Valla
2025-10-26 23:03 ` [PATCH RFC 1/3] drm: client: add splash client Francesco Valla
2025-10-26 23:03 ` [PATCH RFC 2/3] MAINTAINERS: add entry for DRM " Francesco Valla
2025-10-26 23:03 ` [PATCH RFC 3/3] drm: docs: remove bootsplash from TODO Francesco Valla
2025-10-27 10:09 ` [PATCH RFC 0/3] Add splash DRM client Maxime Ripard
2025-10-27 12:35 ` Thomas Zimmermann
2025-10-27 16:01 ` Mario Limonciello
2025-10-27 16:28 ` Maxime Ripard
2025-10-27 16:31 ` Mario Limonciello
2025-10-27 17:19 ` Maxime Ripard
2025-10-28 8:09 ` Francesco Valla
2025-10-28 13:39 ` Mario Limonciello
2025-10-29 8:36 ` Maxime Ripard
2025-10-28 8:03 ` Francesco Valla
2025-10-28 7:58 ` Francesco Valla
2025-10-29 8:34 ` Maxime Ripard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=k5ktlmzszlk2qzn4mteduardoda7npxyd6m5rn6avjneayoqbw@q32utxpy7lk6 \
--to=mripard@kernel.org \
--cc=airlied@gmail.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=francesco@valla.it \
--cc=javierm@redhat.com \
--cc=jfalempe@redhat.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=sam@ravnborg.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).