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

 drivers/firmware/efi/libstub/efi-stub.c |   2 +-
 drivers/firmware/efi/libstub/efistub.h  |  31 +++++-
 drivers/firmware/efi/libstub/gop.c      | 137 +++++++++++++++---------
 drivers/firmware/efi/libstub/x86-stub.c |   3 +-
 include/linux/efi.h                     |   4 +-
 5 files changed, 120 insertions(+), 57 deletions(-)

-- 
2.51.0

On Wed, 15 Oct 2025 at 18:08, Thomas Zimmermann <tzimmermann@suse.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.

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)

Hi

Am 14.11.25 um 09:31 schrieb Ard Biesheuvel:
> On Wed, 15 Oct 2025 at 18:08, Thomas Zimmermann <tzimmermann@suse.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.

> - make CONFIG_FIRMWARE_EDID depend on (X86 || EFI_STUB)

See the attached patch.

Best regards
Thomas


-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)

On Mon, 17 Nov 2025 at 09:02, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 14.11.25 um 09:31 schrieb Ard Biesheuvel:
> > On Wed, 15 Oct 2025 at 18:08, Thomas Zimmermann <tzimmermann@suse.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.

On Tue, 18 Nov 2025 at 17:52, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 17 Nov 2025 at 09:02, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >
> > Hi
> >
> > Am 14.11.25 um 09:31 schrieb Ard Biesheuvel:
> > > On Wed, 15 Oct 2025 at 18:08, Thomas Zimmermann <tzimmermann@suse.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.