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

[Màxim Pedraza Padilla]

Hi Sam, Francesco,

Sam -- thanks, and you're right that it's doable. One honest nuance on
where it would live: CLUT224 isn't a DRM fourcc, it's the kernel logo's
own container -- a palette plus one index byte per pixel. drm_format_helper
converts between pixel formats, which is a symmetric operation; turning
CLUT224 into RGB is a palette decode, not a reformat. It can certainly sit
there, but it's worth calling it what it is: a decompression step in front
of the scanout, not a format conversion next to the xrgb8888->rgb565 helpers.

Francesco -- that's exactly the crux, and I think we agree completely. The
palette expansion is cheap for me only because the image is small and
low-resolution: one lookup per pixel at 800x480 costs nothing, so I get the
17 KiB on flash for free at boot. But that's the "low-resolution sweet spot"
you describe, not the general case -- at a generic resolution the per-pixel
decode stops being free, and boot time is the whole point. So I don't think
paletted input belongs in a client whose goal is to stay generic; it's a
trade that only pays off when the image is deliberately small.

For the case where nothing lights the panel before Linux -- Falcon boot,
or a handover where the buffer doesn't survive -- I do have to draw, and
there I'd rather build on your series than start from scratch. I can't use
it unchanged, since my logo isn't a BMP: it's a small CLUT224 (paletted)
blob carried in the device tree, so I'd add a source alongside your BGRT
and firmware-BMP ones that recognises it by a magic and decodes the palette.
But the client structure, the drm_client_setup() hook, the scanout path --
that's all your groundwork, and I'd be leaning on it. Thanks for the offer
to help on a respin, and for the series, which is what made the distinction
clear to me.

Max

El mar, 18 ago 2026 a las 21:39, Francesco Valla
(<francesco@xxxxxxxx>) escribió:
>
> 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
>