Re: [RFC PATCH 0/6] Boot logo supplied by the device tree

On Thu, Aug 13, 2026 at 01:50:47AM +0200, Màxim Pedraza Padilla wrote:
> El mié, 12 ago 2026 a las 9:42, Maxime Ripard (<[email protected]>) escribió:
> > In such a case, you can (and really should) use KMS, and you should use
> > an initramfs and setup the splash screen there.
> 
> Agreed that readout is the right answer where it applies, and I am not
> looking to duplicate it. Three cases where it does not:
> 
>   - Hardware whose only in-tree display driver is fbdev. There is no KMS
>     state to read at all, and there are still around a hundred of those
>     drivers.

Which are entirely deprecated, and kept mostly for historical reason.
It's kind of irrelevant to this discussion.

>   - DRM drivers without readout implemented, which today is all of them
>     but tidss.

The obvious answer to that being "just implement readout then". We won't
merge a core feature to accomodate a driver not implementing an existing
feature.

>   - Falcon mode, where U-Boot proper never runs, so there is no image and
>     no programmed CRTC to inherit.

In this case, the first modeset is fine, and whoever does it doesn't
matter, so it might as well be userspace.

> On the initramfs: it moves the splash earlier, it does not close the gap.

Which gap are you talking about?

> Measured on our 4.19 product kernel:
> 
>   1.09 s  tilcdc registers fb0, the logo can be drawn
>   2.68 s  ubi0 starts attaching        <- 1.59 s of built-in driver probes
>   3.39 s  Run /sbin/init               <- 0.70 s of UBI attach + UBIFS mount
> 
> An initramfs removes the 0.70 s of storage. It cannot remove the 1.59 s,
> because PID 1 does not exist until the initcalls have run.

I mean, sure it can. Move built-in drivers to modules, and load them in
the initramfs. It will reduce the kernel image size (so load and
decompression time) and the kernel boot time itself.

I personally did a subsecond boot to userspace with Falcon Boot, UBI and
a similar platform (and no initramfs). 3.4s to run init seems subobtimal
to me.

> So the gap goes from 2.3 s to roughly 1.6 s, before the splash binary
> has loaded and drawn anything. That figure is an estimate; the
> breakdown it comes from is not.
> 
> It is also worth saying what this series is and is not. The kernel has
> drawn a boot logo for decades; this does not add that. It changes where the
> image comes from, so that one kernel binary can serve products that differ
> only in branding. If the position is that the kernel should not draw a logo
> at all, that is an argument about CONFIG_LOGO rather than about these
> patches -- and drm_panic already calls fb_find_logo(), so the logo is not
> purely an fbdev concern either.

I understand where you're coming from. On the flip-side, why should we
add an interface we'll have to maintain forever, while making a
compromise because the fact that it should be in the DT to begin with is
arguable, on a deprecated subsystem, for something where we have
alternatives.

Maxime

-----BEGIN PGP SIGNATURE-----

iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCan16LQAKCRAnX84Zoj2+
dsIUAYCz8NYpNrR0fsfu0V282mWPfF/ktotI46Lnf6bQsRzHz4DDDLe00UF3WRjU
SPEMxgkBgKlNP2ks2w3VUbh6Y8/fw4CerSji2OxDCYcAoQA+5Tgb+Qq57XwD47Xw
Lm9gnS4GVg==
=xQLQ
-----END PGP SIGNATURE-----