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 > >
