[PATCH v7 0/6] Add splash DRM client

["Màxim Pedraza Padilla" <maximpedraza@gmail.com>]

This is the seventh version of the splash client, which I took over from
Francesco with v4. As Thomas suggested [1], it holds only the part that
can go in now: patches 1 to 6 and 8 of v6, with the MAINTAINERS entry
squashed into the patch that adds drm_splash.c. The device tree source
and its binding, the placement and rotation, and the connector
orientation will follow as a separate series on top of this one.

The client draws a splash on every output, including those plugged in
later, until userspace takes over. The image comes from the EFI BGRT or,
failing that, from a BMP loaded as firmware, named at build time
("drm_splash.bmp" by default); with neither, only the background is
drawn, in a colour set at build time. A BGRT image is drawn at the table
offsets, a BMP loaded as firmware is centred. A BGRT whose ACPI 6.2
orientation bits are set is skipped for now; turning it comes with the
rotation in the later series.

Changes since v6
----------------

From the reviews of v6 [1]-[6]:

  - MAINTAINERS: I am listed as M: and Francesco as R:, in patch 4
    (Thomas [2], Francesco [3]).
  - The firmware source is DRM_SPLASH_SRC_FW, and its Kconfig options
    DRM_CLIENT_SPLASH_SRC_FW and DRM_CLIENT_SPLASH_FW_NAME, since the
    BGRT is a BMP too (Thomas [4]).
  - The drm_splash_fw_load() stub returns 0 (Thomas [5]), and
    drm_splash_image_load() does not call it when the firmware source is
    disabled.
  - Thomas, I have kept your Reviewed-by on patch 4, as you said [6].

From sashiko's review of v6 [7], and further review:

  - Patch 4: restore leaves the commit to the work, which draws whatever
    is missing first, so a restore that comes while the device is
    suspended is no longer lost [7]; a forced restore stays forced across
    suspend, and the work commits even when no scanout is left.
  - Patch 4: a hotplug while userspace has the display waits for the
    next restore, as fbdev does; only a lack of memory makes the image be
    drawn again; unregister cancels the work before it looks for a
    firmware request, which the work can now make too; the tile group id
    is read under mode_config.mutex, which an EDID update holds while it
    changes or frees the group.
  - Patch 2: the image address and size are 0 when efi_bgrt_has_image()
    says there is no image, so that they never disagree on kernels with
    32-bit physical addresses.
  - Patch 3: the comment on the DIB header says that a negative width is
    invalid.

Testing
-------

  - QEMU versatilepb (pl111, 16 bpp): no image, and the BMP loaded as
    firmware, compared pixel by pixel.
  - x86-64 with OVMF: the BGRT through the new accessors; with
    CONFIG_DRM_CLIENT_SPLASH_SRC_FW=n, with and without a BGRT
    (bgrt_disable), the background alone and no error.
  - i386 without PAE on 32-bit OVMF, with the BGRT replaced from the
    initrd so that it points above 4 GiB: the background alone.
  - QEMU virt arm64 (virtio-gpu, 32 bpp) with KASAN and kmemleak: the
    driver bound and unbound repeatedly, a crafted bitmap offset, and
    the firmware arriving only after the unbind; no reports. With
    lockdep too, over several outputs, tiled displays and the bind
    cycles: no reports.
  - Several outputs, one of them off, and tiled displays from 2x1 up to
    3x3, 4x2 and 2x4 tiles, in several CRTC orders, simulated with
    DisplayID tiled topology EDIDs on virtio-gpu heads. The layouts with
    more than one row and column need a fix to the client modeset code
    that is not part of this series.
  - The error paths, with a debug patch forcing them: buffers and formats
    that fail on one output, work queued while suspended, a restore
    during suspend or with a master, a hotplug with a master, a fill that
    fails, a firmware request made by the work and raced against the
    unbind; no WARN or KASAN report in any of them.
  - An AM335x board (tilcdc, 16 bpp), booting over TFTP and NFS, with
    the BMP built in and from an initramfs, an 8 bpp BMP that is
    rejected, and 5 unbind and bind cycles of tilcdc, checked by reading
    the scanout buffer back.
  - W=1 and sparse clean; every patch builds on its own on arm and
    x86-64; checkpatch --strict clean apart from a quoted modpost line in
    patch 2 and the MAINTAINERS reminder on patch 3, whose new header
    FRAMEBUFFER LAYER already covers.

Open questions
--------------

  - Unbinding waits for a pending firmware request, as it cannot be
    cancelled and its callback uses the splash, and it waits under the
    device's clientlist_mutex. Normally the request is long over; with
    the sysfs fallback it can take up to the loading timeout. Not
    waiting would mean giving the callback its own refcounted object;
    I can do that as a follow-up.
  - The BGRT offsets are for the mode the firmware drew in. When KMS
    picks another one, the x86 check taken from efifb leaves the screen
    without a logo, and elsewhere the logo lands off centre. The offsets
    could be used only when the scanout matches the firmware's
    framebuffer, and the image centred otherwise.
  - The splash is a DRM client, so a device using it has no fbdev
    emulation and no /dev/fb0.

Based on drm-misc-next-2026-10-23 (cf5d8e390e2a).

[1] https://lore.kernel.org/all/066197a1-aa2b-455b-84d8-4e2215fad764@suse.de/
[2] https://lore.kernel.org/all/ed28619d-6ca7-46aa-82c0-c83f30a836e3@suse.de/
[3] https://lore.kernel.org/all/avTjrfIEPgyvPDti@bywater/
[4] https://lore.kernel.org/all/8eaf9955-485f-4908-bb65-1e0c3184fb36@suse.de/
[5] https://lore.kernel.org/all/c2cbc13a-a58d-4c0b-87ac-62daa6de6fba@suse.de/
[6] https://lore.kernel.org/all/4762a951-5b37-4e7a-8569-f55a4683c912@suse.de/
[7] https://lore.kernel.org/all/sashiko-outbox-186719@kernel.org/

v6: https://lore.kernel.org/r/20261027135342.2003632-1-maximpedraza@gmail.com
v5: https://lore.kernel.org/r/20261013093243.505776-1-maximpedraza@gmail.com
v4: https://lore.kernel.org/r/20261001195847.141192-1-maximpedraza@gmail.com
v3: https://lore.kernel.org/r/20260510-drm_client_splash-v3-0-a9aee9f0b2fc@valla.it
v2: https://lore.kernel.org/r/20260106-drm_client_splash-v2-0-6e86a7434b59@valla.it
v1: https://lore.kernel.org/r/20251027-drm_client_splash-v1-0-00698933b34a@valla.it

Màxim

Francesco Valla (2):
  drm: client: add splash client
  drm: docs: remove bootsplash from TODO

Màxim Pedraza Padilla (4):
  drm/clients: Kconfig: indent DRM_CLIENT_DEFAULT with tabs
  efi: bgrt: add accessors for the boot graphics
  fbdev: efifb: move the BMP headers to <video/bmp.h>
  drm/client: splash: pick the image source in one place

 Documentation/gpu/todo.rst                    |   17 -
 MAINTAINERS                                   |    8 +
 drivers/firmware/efi/efi-bgrt.c               |   76 +-
 drivers/gpu/drm/clients/Kconfig               |   80 +-
 drivers/gpu/drm/clients/Makefile              |    1 +
 drivers/gpu/drm/clients/drm_client_internal.h |    9 +
 drivers/gpu/drm/clients/drm_client_setup.c    |    8 +
 drivers/gpu/drm/clients/drm_splash.c          | 1060 +++++++++++++++++
 drivers/video/fbdev/efifb.c                   |   49 +-
 include/linux/efi-bgrt.h                      |   39 +-
 include/video/bmp.h                           |   40 +
 11 files changed, 1330 insertions(+), 57 deletions(-)
 create mode 100644 drivers/gpu/drm/clients/drm_splash.c
 create mode 100644 include/video/bmp.h


base-commit: cf5d8e390e2ac2cfa24a50645efdbb9f0eebe65f
-- 
2.39.5