Hi,
On Sun, Aug 02, 2026 at 12:01:58AM +0200, Màxim Pedraza Padilla wrote:
Uwe Kleine-König wrote:
quoted
My 0.02€: Usually you want to use the display using drm and not fb once
the machine is fully booted. If you're using fb during boot to display a
logo, it's hardly possible to switch to drm later in the boot process
without flicker.
So my recommendation for your usecase is to not use the kernel boot logo
stuff, but something like https://github.com/pengutronix/platsch.
Thanks for the pointer, I did not know platsch and it looks like a good
fit for the problem it solves. It does not solve mine, though, and I
think the reason is worth spelling out, because it is not about how the
image gets drawn but about when.
These are industrial units, and the requirement is time to first pixel
after power is applied. If the panel stays dark for more than a moment
the unit reads as dead, and that is a support call. Anything running in
userspace is by construction later than the kernel: it needs the kernel
booted, the rootfs mounted and init far enough along to exec it. I can
measure the exact difference on our hardware if that is useful for the
discussion.
We do already paint a BMP from U-Boot, which is as early as we can
possibly be. The problem is the gap that follows: once the display
driver probes, the panel is cleared, and nothing puts anything back
until userspace is running. Moving the logo further out into userspace
widens that gap rather than closing it. The kernel boot logo is what
fills it, and that is the whole reason this series exists.
If the sole reason for this series is to keep having something on the
display while the kernel boots until DRM catches up, then you probably
want to check
https://lore.kernel.org/r/20260629-drm-state-readout-v4-0-5966657980ed@kernel.org (local)
Which also does what you're trying to achieve: keep the display running
with the same content while the DRM driver loads, and switch to whatever
comes next without a flicker (if we can).
Maxime