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 ([off-list ref]) escribió:

quoted

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