Message-ID: <CAMj1kXHKc4jJnQ9x+sUhAO54PeZ6QN6yzcHVTovGvunp2QYnDA@mail.gmail.com>
Date: Tue, 18 Nov 2025 17:52:11 +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 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.

Powered by blists - more mailing lists