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.
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.
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;
- 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?
If you are happy with it, I'll take you up on your offer.
Màxim
El vie, 25 sept 2026 a las 21:32, Francesco Valla
(<[email protected]>) 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
>
