Hi, This series is superseded by RFC v4 of the DRM splash client, which adds the device tree support there, as Thomas suggested:
https://lore.kernel.org/all/[email protected]/ The node placement and the reserved memory region carried over; the clut224 format and the ppmtodtlogo tool did not, as the client takes BMP images. Helge, please drop this one. Thanks to everyone who reviewed it. Màxim El mié, 30 sept 2026 a las 8:32, Francesco Valla (<[email protected]>) escribió: > > 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 > > (<[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 > > >
