On Tue, 18 Nov 2025 at 17:52, Ard Biesheuvel <[email protected]> wrote: > > On Mon, 17 Nov 2025 at 09:02, Thomas Zimmermann <[email protected]> wrote: > > > > Hi > > > > Am 14.11.25 um 09:31 schrieb Ard Biesheuvel: > > > On Wed, 15 Oct 2025 at 18:08, Thomas Zimmermann <[email protected]> > > > 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.
