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

[Francesco Valla <francesco@valla.it>]

Hi Màxim,

On Tue, Aug 18, 2026 at 12:48:21AM +0200, Màxim Pedraza Padilla wrote:
> Hi Sam,
> 
> Thank you -- that's a useful pointer, and it settles the question of how
> a splash should be drawn without fbcon: a DRM client at
> drm_client_setup(), next to drm_log, not a drm_fb_helper hook.
> 
> Francesco's series is genuinely inspiring work, and it would be very
> useful to me if it could take a CLUT224 image -- unfortunately it can't.
> It only accepts an uncompressed 24-bit RGB888 BMP, whereas our logo is
> paletted, which is what keeps it small: 17 KiB for 800x480 rather than
> around a megabyte. So as it stands the format doesn't line up with what
> we carry.

Format concerns are - in addition to lack of time to work on it - what
is keeping me from sending a new revision. Any kind of compression would
need to be unwinded - probably on a per-pixel basis - making the
required CPU time unreasonable for large images (at least if boot time
optimization is the ultimate goal - linke in my case).

Of course, on "low-resolution" displays the size-vs-time tradeoff might
be the sweet spot - but the target here was to being as much generic as
possible.

> 
> Reading it did make the distinction clearer to me, though. drm_splash
> *draws* an image into a fresh buffer, which means a first modeset and the
> blanking that comes with it. What our hardware leaves us with is a
> framebuffer U-Boot has already drawn and a CRTC still scanning it out, so
> for our case the natural thing is to *adopt* that state rather than
> redraw it -- which is what hardware state readout does, with no redraw
> and no flicker.
> 
> Where drm_splash is the right tool is the case with no state to adopt --
> Falcon boot, where U-Boot proper never runs, or a handover where the
> buffer doesn't survive. I'll follow Francesco's series for that.

My typical embedded setup is exactly that one - Falcon boot, a simple
boot logic inside the SPL, and possibly no initramfs. I find this to be
the most portable solution, as it does not require complex drivers and
handover logic in the bootloader.

In case you decide to take my series for a re-spin, feel free to ask if
something is unclear.

> Thanks again -- it helped me draw the line between the two.
> 
> Max

Reagrds,

Francesco