Message-ID: <CAMj1kXEg2PKHJSnko8eFz8fVRDZYTuUYfKCD+jYwuFr=oaUiOg@mail.gmail.com>
Date: Tue, 18 Nov 2025 20:41:43 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: jonathan@...ek.ca, javierm@...hat.com, linux-efi@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] efi: x86: Provide EDID from GOP device

On Tue, 18 Nov 2025 at 17:52, Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Mon, 17 Nov 2025 at 09:02, Thomas Zimmermann <tzimmermann@...e.de> wrote:
> >
> > Hi
> >
> > Am 14.11.25 um 09:31 schrieb Ard Biesheuvel:
> > > On Wed, 15 Oct 2025 at 18:08, Thomas Zimmermann <tzimmermann@...e.de> wrote:
> > >> Add support for EFI_EDID_ACTIVE_PROTOCOL and EFI_EDID_DISCOVERED_PROTOCOL
> > >> on x86. Refactor the GOP helpers for EDID support, then retrieve the EDID
> > >> into x86 boot_params.
> > >>
> > >> Later boot code copies the EDID from the boot parameters into the global
> > >> variable edid_info. Graphics drivers, such as efidrm, can pick up the
> > >> information from there. In the case of efidrm, it provides the EDID to
> > >> user-space compositors, which use it for improved QoS on the display
> > >> output. Similar functionality is already available on old VESA systems
> > >> with vesadrm.
> > >>
> > >> Tested on x86 EFI systems.
> > >>
> > >> Another patch is required to provide EDID on non-x86 systems via the
> > >> generic EFI stub. The implementation can directly build upon this
> > >> series.
> > >>
> > >> Thomas Zimmermann (5):
> > >>    efi: Fix trailing whitespace in header file
> > >>    efi/libstub: gop: Find GOP handle instead of GOP data
> > >>    efi/libstub: gop: Initialize screen_info in helper function
> > >>    efi/libstub: gop: Add support for reading EDID
> > >>    efi/libstub: x86: Store EDID in boot_params
> > >>
> > > Hi,
> > >
> > > Apologies for the delay. This series looks fine to me, although I
> > > would prefer it if we could make things a bit more generic?
> > >
> > > Everything you are adding here is arch-agnostic, except for the bit
> > > where we use x86-specific plumbing to pass the EDID info between the
> > > EFI stub and the core kernel.
> >
> > Attached is an RFC patch that I already have. This would be the next
> > step for EDID support. I've not yet sent the generic-EFI patch, as I did
> > not have opportunity to test it. The patch addresses most of what you
> > ask for, I think.
> >
> > >
> > > More specifically, could we do the following:
> > > - move struct edid_info edid_info into common code
> >
> > edid_info is related to screen_info, so it follows the same conventions.
> > Arnd Bergmann made x86-specific changes for screen_info in commit
> > b8466fe82b79 ("efi: move screen_info into efi init code"). x86 has it's
> > own thing, sort of. See the attached patch for my non-x86 solution.
> >
> > > - pass the detected EDID info block via a EFI config table instead of
> > > boot_params
> >
> > The x86 code uses boot params for screen_info already and also transfers
> > edid_info on VESA systems via boot params (or if grub set up boot_params
> > for us). [1] It's all there and working already. If we transfer
> > edid_info via config table, we'd need extra code on x86.
> >
>
> I understand the x86 already uses edid_info for non-EFI boot, but that
> doesn't mean we have to introduce new dependencies on legacy bits like
> boot_params to the EFI stub.
>
> For generic EFI, I don't think it is necessary to clone all the config
> table logic with GUIDs and stuff. Instead, given that the EFI stub is
> tightly coupled with the kernel anyway, we can just decide that the
> config table has both a screen_info and a edid_info struct, and the
> generic EFI code consuming the config table populates both.

I've queued this up for now so it can soak in -next for a bit, but
please let's not leave non-x86 behind here.

Powered by blists - more mailing lists