Re: [PATCH v3 0/7] Boot logo supplied by the device tree

[Francesco Valla]

Hi Màxim,

On Tue, Sep 29, 2026 at 01:46:36PM +0200, Màxim Pedraza Padilla wrote:
> Hi Francesco,
> 
> > v4 is planned but has been preempted by other activities - I am not able
> > to give you an ETA at the moment. If you have capacity, feel free to
> > take over.
> 
> Thanks, I appreciate it. Since it is your series, I would like to run
> past you what I would change before taking it on.
> 
> The v4 would still be an RFC, based on drm-misc-next. Your patches keep
> your authorship, with any fix to them folded in and noted in the commit
> message.
> 
> Fixes to what is in v3:
> 
>   - the BGRT symbols exported, as in your patch for Mario, but with
>     EXPORT_SYMBOL_GPL;
>   - drm_splash_init_client() indexes modeset_mask by the number of
>     modesets added in the first loop and by the number walked in the
>     second, so an output without a mode ahead of a connected one gets
>     the buffer instead;
>   - for a tiled group, the first loop dereferences tiled->buffer before
>     any buffer exists, and the width and height look swapped;
>   - if the BMP firmware never arrives, the callback returns without
>     waking the render thread, which is left in TASK_UNINTERRUPTIBLE for
>     good;
>   - the 24 bit blitters read each pixel as an unaligned u32, one byte
>     past the image when the rows have no padding;
>   - the image cleanup always calls memunmap(), which will need to know
>     where the image came from once there is a third source;
>   - the spaces in DRM_CLIENT_DEFAULT, in a patch of its own.
>

I suggest you also take at look at the review sashiko did for the V3
[1], as it contains some good suggestions (some of them are already
present in your list).

> The modeset, tiling and render thread ones come from reading the code,
> so I will reproduce them in qemu first. Tiling I cannot test at all.
>

I did not test tiling as well - I think it's a mode limited to some
Intel cards?

> Additions:
> 
>   - a device tree image source: a node under /chosen with the BMP either
>     in the node itself (dtc's /incbin/) or in a reserved memory region,
>     mapped with the same memremap() as the BGRT;

A reserved memory region is (probably) a better idea, to allow change
the splash without recompiling the devicetree.

A possible usecase would be:

 - bootloader reads the BMP image from a dedicated partition and loads
   it to the reserved memory (very much like the BGRT path);
 - splash client parses the devicetree, finds the memory region and
   loads the image from there;
 - userspace updates the dedicated partition with a different image.

>   - placement from that node, a position with -1 centring an axis plus
>     an offset, instead of always centring;
>   - rotation, for the DT image and for BGRT images with the orientation
>     bits set, which are skipped today;
>   - the background colour coming from the same place as the image: the
>     DT node can carry its own, splash_color goes with splash_bmp, and
>     the Kconfig colour stays the default for everything else, BGRT
>     included.
> 
> The sources would be tried in the order DT, BGRT, BMP firmware, and
> then just the colour. A DT node is only there if someone put it there
> for that board, so it seemed right to let it win.
> 
> Does that match what you had in mind? And how would you like to appear
> in MAINTAINERS, as a maintainer next to me or as a reviewer?
> 

Yes, please, either as a co-maintainer or as a reviewer, as you see fit.

> If you are happy with it, I'll take you up on your offer.
>

Thank you for continuing the effort on this - I still believe it's
useful, but currently is not fitting inside my schedule.

> Màxim
> 

Regards,
Francesco


[1] https://sashiko.dev/#/patchset/20260510-drm_client_splash-v3-0-a9aee9f0b2fc%40valla.it

> El vie, 25 sept 2026 a las 21:32, Francesco Valla
> (<francesco@xxxxxxxx>) escribió:
> >
> > Hi Màxim,
> >
> > On Fri, Sep 25, 2026 at 10:48:31AM +0200, Màxim Pedraza Padilla wrote:
> > > Hi Thomas,
> > >
> > > > the whole Linux logo on the console is somewhat gimmicky and IMHO should
> > > > not be further extended. Also fbdev as a whole has realistically run its
> > > > course. We fix bugs and occasionally clean up the code, but it is
> > > > questionable whether new feature make much sense. Even more so as the
> > > > drivers your system uses appear to be DRM ones.
> > >
> > > They are, it is tilcdc. Understood, I will drop the fbdev side, which
> > > also settles your comment on patch 1.
> > >
> > > > There is a proposal for a DRM splash screen at [1]. It retrieves the
> > > > device vendor's logo from the firmware and displays it at the given
> > > > coordinates. IMHO you should start with this series and add DT support
> > > > there.
> > >
> > > Agreed. I have been following Francesco's series since Sam pointed me
> > > at it, and it is where the DRM follow-up I mentioned in the cover letter
> > > belongs, rather than in a client of my own.
> > >
> > > A device tree source fits next to the BGRT one. The BGRT is the firmware
> > > handing the kernel an image and where to put it, and a DT system has no
> > > such table. The BMP loaded as firmware only helps if the file is built
> > > into the kernel, or if a filesystem is already there when the display
> > > comes up. With U-Boot's Falcon mode, the device tree is the only thing
> > > that reaches the kernel.
> > >
> > > So the plan would be a node under /chosen carrying a BMP, either in the
> > > node itself or in a reserved memory region the bootloader loaded it
> > > into, with the placement properties from this series. The region is the
> > > same memremap() the BGRT source already does, only with the address
> > > coming from the device tree.
> > >
> > > Rotation too: the client skips a BGRT image with the orientation bits
> > > set today, and it could turn it instead. I will ask Rob separately how
> > > he wants the image described, since that is what the binding hinges on.
> > >
> > > Francesco, is a v4 on the way? Would you take a DT source as patches on
> > > top of your series, or would you rather I wait until it lands?
> > >
> >
> > v4 is planned but has been preempted by other activities - I am not able
> > to give you an ETA at the moment. If you have capacity, feel free to
> > take over.
> >
> > > Max
> > >
> >
> > Regards,
> > Francesco
> >