Hi, On 13-Oct-25 10:04 AM, Javier Martinez Canillas wrote: > Thomas Zimmermann <[email protected]> writes: > > Hello Hans, > >> Hi Hans >> >> Am 11.10.25 um 12:02 schrieb Hans de Goede: >>> Hi, >>> >>> A while ago I did a blogpost about not having the native GPU drivers in >>> the initrd: https://hansdegoede.dreamwidth.org/28291.html >>> >>> With the Fedora /boot partition size increase there has been renewed >>> interest in this and as a result I got an interesting comment on >>> the blog post pointing out that there are EFI protocols to get EDID >>> info for the monitor (presumably for the one the GOP has lit up). >>> >>> It would be useful to see if we can hook this up so that the simpledrm >>> device can report the physical dimensions of the screen and the boot >>> splash does not need to guess the DPI and thus does not need to guess >>> whether to do hiDPI scaling or not. The comment is here: >>> >>> https://hansdegoede.dreamwidth.org/28291.html?thread=14467#cmt14467 >>> >>> and it points to: >>> >>> https://uefi.org/sites/default/files/resources/2_-_AMD_UEFI_Plugfest_EDID_Spring2012.pdf >>> https://uefi.org/specs/UEFI/2.9_A/12_Protocols_Console_Support.html >>> >>> Unfortunately I do not have time to work on this myself, hence this >>> email in the hope that someone else can pick this idea up. >> >> There are now efidrm and vesadrm, which support specifically the >> features that we get from the rsp. standards, hardware and bootloader. >> For VESA and EFI the EDID can be transferred from grub via bootparams. A >> patch [1] is on its way into upstream grub. The Linux kernel stores that >> data in edid_info, from where it is picked up by efidrm and vesadrm. If >> the EFI framebuffer comes directly from the EFI calls, we need to >> implement this in the kernel, but the principle is the same. I also have >> ideas for making this work on Coreboot. >> >> For simpledrm, I'd rather strip if from the ability to use EFI/VESA >> framebuffers and focus on simple-framebuffer DT nodes. These sometimes >> come with DPI information. Maybe we could extend the DT to support EDID >> as well. >> >> [1] https://lists.gnu.org/archive/html/grub-devel/2025-10/msg00043.html >> >> I have long been working on all this and it is now slowly coming together. >> > > I agree with Thomas. > > We are still not enabling these DRM drivers in Fedora though, but maybe it > is time to do that and just disable CONFIG_SYSFB_SIMPLEFB. I can propose a > change request for Fedora 44 to do this.
Trying to drive this forward by enabling this in Fedora 44 so this gets more test coverage sounds like a good plan to me! Thanks & Regards, Hans
