From: Francesco Valla <francesco@valla.it>
To: "Màxim Pedraza Padilla" <maximpedraza@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
Helge Deller <deller@gmx.de>, Simona Vetter <simona@ffwll.ch>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Maxime Ripard <mripard@kernel.org>,
linux-fbdev@vger.kernel.org, devicetree@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/7] Boot logo supplied by the device tree
Date: Fri, 25 Sep 2026 21:31:56 +0200 [thread overview]
Message-ID: <arbLHvCBqxG7zcf_@bywater> (raw)
In-Reply-To: <CAEUXW=G2a=Qz-9P_2+EFe-GiW4WqdOjtSCxoO4P15u_J48nP9g@mail.gmail.com>
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
prev parent reply other threads:[~2026-09-25 19:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 20:10 Max Pedraza
2026-09-23 20:10 ` [PATCH v3 1/7] fbdev: describe where the boot logo goes in one place Max Pedraza
2026-09-24 12:05 ` Thomas Zimmermann
2026-09-23 20:10 ` [PATCH v3 2/7] dt-bindings: display: add a device tree supplied boot logo Max Pedraza
2026-09-24 11:49 ` Rob Herring (Arm)
2026-09-25 8:58 ` Màxim Pedraza Padilla
2026-09-23 20:10 ` [PATCH v3 3/7] video: logo: allow the boot logo to come from the device tree Max Pedraza
2026-09-23 20:10 ` [PATCH v3 4/7] fbdev: honour the device tree boot logo placement properties Max Pedraza
2026-09-23 20:10 ` [PATCH v3 5/7] dt-bindings: display: allow the boot logo in a reserved memory region Max Pedraza
2026-09-23 20:10 ` [PATCH v3 6/7] video: logo: allow the boot logo to come from " Max Pedraza
2026-09-23 20:10 ` [PATCH v3 7/7] video: logo: add ppmtodtlogo host tool Max Pedraza
2026-09-24 12:21 ` [PATCH v3 0/7] Boot logo supplied by the device tree Thomas Zimmermann
2026-09-25 8:48 ` Màxim Pedraza Padilla
2026-09-25 19:31 ` Francesco Valla [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arbLHvCBqxG7zcf_@bywater \
--to=francesco@valla.it \
--cc=conor+dt@kernel.org \
--cc=deller@gmx.de \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=krzk+dt@kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maximpedraza@gmail.com \
--cc=mripard@kernel.org \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®