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

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.
  - DRM drivers without readout implemented, which today is all of them
    but tidss.
  - Falcon mode, where U-Boot proper never runs, so there is no image and
    no programmed CRTC to inherit.

On the initramfs: it moves the splash earlier, it does not close the gap.
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. 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.

On doing it through KMS: you are right, and the follow-up series should be
a DRM client alongside drm_log rather than a hook in drm_fb_helper. I will
rework it that way before posting it.

Max