From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.128.47 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794784924; b=IQar4zjbcqg2d3jH7vWVOTfxVbUCdFA6n98uP86Tz2gXEBXyonTQEs/YICnKNgslgTIc Z5Wq+q8xTMn0qQ6HB2xgOBcZK0uKZhbr2aOkDQZTg7gQj4yDh810yuocI03iG1LAWmKHj hZAIx9QVI4qN6+xYKleUEqXWcSoRaeAdWdDOhCiuU223vjmK1+iuN3enB/DJWwweecpWO vyYloiDdxbx8mVAunfohugfDTE7EQxYtLA2YrGAuQHuAKT5ULWocQiMcdxyms+ZmhFJaC CCSc6CSi9l+eupxKBtiHjR4yeIP2FgrMBSGlDQyaVxkNEqpwClGpoPvM4L1TaqZfM1Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794784924; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=zAejWuLH6A6kWbjxkZ2dzmDOuVhvhpj01tnf5xLhIOA=; b=cRpWhQX+QHr6pcSuIH0xKLF6xOMffgSpgFe+X3K1+YjBcdqvprOibW1AUaqn+1k6k150 Me/dCo2La3eHtEk0YSvCyPK4uJcZw+SLplzYQmToN35ubvfgXxWC07pI+zsUgYXuhGzId YQ5AOb3Bpquujp6wueiAiIBr1KnrFTXjvktNxfgSZksQFJAC0coq7d3eg1v9/rnC87ymn aAuLykStLfjjH5BYJSiSZb4IJMehHBKDVGCwCuhvJK7EFeVCEcws/8gpOzK/EzvLyBzIr qZh5DkCRN2QqCuMPrXYMQ1QyXzbr2kh+AYaz2VFA1KOumPsewsN3YAiQ8aNcvEVGWEQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=L78fOILN; arc=none smtp.remote-ip=209.85.128.47 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E149606A333 for ; Sun, 15 Nov 2026 23:22:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 5E149606A333 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=L78fOILN Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4bb68c197c7so10530305e9.1 for ; Sun, 15 Nov 2026 15:22:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794784923; x=1795389723; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zAejWuLH6A6kWbjxkZ2dzmDOuVhvhpj01tnf5xLhIOA=; b=L78fOILNmFl2yRucuBd+RTaXWGuOJvcIykScC6o4ql3NvgDtxFGSzvX7Wb/mtz1gB+ VvaUY7a1I3RjWNeLCZPU5TYNEbggTLRKhVo5HzyHvA8mEYBsCXX1Do1SMe6lOraR0yq2 YsZczkGxxNJ7SwdmGEVRjrgeFxTY5GIJf/h9eu4rnRPyKFrJPkRH4VP4WjVUgAm1s2kI wIaZ8A0Ymt/FxMFyg5/Hq8uZrKPvAGYW+39fg/TNnXdk1kdJGJ+7erQ48zxTdAY3/+S/ mSiUuFj7yJ3nw5LFjtA24ETQM6Rb/xq+GSOodQMTAtS7v534rN3gvysBU4hcu2/y33TF Q7rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794784923; x=1795389723; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=zAejWuLH6A6kWbjxkZ2dzmDOuVhvhpj01tnf5xLhIOA=; b=oy/OcDi7GBdinOBwEhfV1tPlxIq2vjRtQAaW1/HBeF7rwxBvbaLF1kHM1eOUqwkSIv RYebF5qmHvNgtRsWgy0iZh22qrRi01dSkBPW2xbiRMTwpCpDMpxnAf2hF5hk0rVCl3ry G5u1jWV7i21OdawqoZfzG8526tcCgGGg1gK/PbmyY3T8p4/U3V/Fqs55WzuCyBCTXdtj I+W+xuKy50lJANWERRS3Ez4sRRDiCE2iHXiz9Z0ZmaigXGytX6iThElbr38VQY9sl/pF p8r448UMs/glBvrHqXbnb7tvAjrTm6vhnlGH20A8gC2EQf9EJXPhVt0E81Kd1BER1Xus M2lA== X-Forwarded-Encrypted: i=1; AL+hErE3UmOwLjUU0Ac63rn6eu/medVVB40HBHLnCcCqQaVDRx5ulMBKPVNRHavJycoXQJDHzHZNzTBUIYw=@vger.kernel.org X-Gm-Message-State: APuU4Z+kIuEOaCIJ8Tl6TJEFKX4yEWxhjXHJrNNDzioVtRK3klS+G1D5 7S+9RkNqNtq/+x/oMmf4D44emcWZfKHUd+WQIxh2XUqjLVKx6zhA7ezk X-Gm-Gg: AYBFou2MplsXygpUO1E5cTfawvWNPYLzZbeQirI3eX4PQG0aHokfTGScKo5u9PwTBp0 C8Z4ttUz3YdAJiks2dAjAaXAG5gYHxZOq6c3/Fpuyoqf8rrxpBIVryFQt+LDFa8piEKR8JQ8FTt Sjg/rUAV7BOU2VTpVXhLwK8mhHImWyIrIUtSGvOJmagHD7RUy6dVhCw8EYe0dBWHoLFIpq7l32M zgGy/6WPFCqX/qIn0iaDMPEtrdD5v9Tt0lCnEa+AM0e2xdh7xg9HLLowv6bKBd3kvcEHFxcpv9k SQ5XDUdOOrrXWtiqXy1+bIif4BZIMboAe8B2O9GfDUAUAWtshk413IBDfEGU8GFebJz33INrkEy KKOGv2jPG6pabPtWUbkCjFVWAjdLE2oC9DewkS/ECtWdpAfwEBoGcukIv24pmNleylaDZ3/1Vzh RNL2rmJd5EZEgnM64hMMmc3oKXqCL7tp32dWF53XUVP0EedGbhVlXdQQW5PG+6F32MR/v14uobO pDzlc3p8n1VL9na7SJlxJ0WJBNJE3JwA4nJ4c2HxCtjezxE2RdTvTnWm/CF637j3KMEquO16U1q Gs3rCkUIE4lOAiBHj7yUqq6QlyyLbrTU379JLQeoCChK1qaHEPquOgc= X-Received: by 2002:a05:600c:83c5:b0:4a7:7d22:c50c with SMTP id 5b1f17b1804b1-4bb55a23b36mr182171115e9.2.1794784922517; Sun, 15 Nov 2026 15:22:02 -0800 (PST) Received: from ingenieria31.oficinasStQ.local ([79.117.0.220]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4bb571f976esm127920955e9.3.2026.11.15.15.21.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Nov 2026 15:22:01 -0800 (PST) From: =?UTF-8?q?M=C3=A0xim=20Pedraza=20Padilla?= To: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Ard Biesheuvel , Jonathan Corbet , Helge Deller , Peter Jones Cc: Francesco Valla , Jani Nikula , Mario Limonciello , Javier Martinez Canillas , Jocelyn Falempe , Sam Ravnborg , Ilias Apalodimas , Shuah Khan , Randy Dunlap , dri-devel@lists.freedesktop.org, linux-efi@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v7 0/6] Add splash DRM client Date: Mon, 16 Nov 2026 01:21:50 +0100 Message-Id: <20261116002156.1027726-1-maximpedraza@gmail.com> X-Mailer: git-send-email 2.39.5 X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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