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

Hi Màxim,

On Tue, Sep 29, 2026 at 01:46:36PM +0200, Màxim Pedraza Padilla wrote:

Hi Francesco,

quoted

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
([off-list ref]) escribió:

quoted

Hi Màxim,

On Fri, Sep 25, 2026 at 10:48:31AM +0200, Màxim Pedraza Padilla wrote:

quoted

Hi Thomas,

quoted

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.

quoted

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.

quoted

Max

Regards,
Francesco