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

Màxim Pedraza Padilla <[email protected]>
Newsgroups org.kernel.vger.linux-fbdev,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <CAEUXW=Ffs+WKsQrNc3zjwtfAO=FKTf_7jQFovD+yjmD_yJuY2Q@mail.gmail.com>
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.

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.

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

Max
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.