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. More specifically, could we do the following: - move struct edid_info edid_info into common code - pass the detected EDID info block via a EFI config table instead of boot_params - make CONFIG_FIRMWARE_EDID depend on (X86 || EFI_STUB)
