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