Le Tue, Jun 01, 2021 at 06:50:24PM +0300, Ville Syrj?l? a ?crit : > On Mon, May 31, 2021 at 10:46:41PM +0200, Anisse Astier wrote: > > The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be > > used for the embedded display. Add support for using it via by adding > > the EDID to the list of available modes on the connector, and use it for > > eDP when available. > > > > If a panel's EDID is broken, there may be an override EDID set in the > > ACPI OpRegion mailbox #5. Use it if available. > > Looks like Windows uses the ACPI _DDC method instead. We should probably > do the same, just in case some crazy machine stores the EDID somewhere > else. Thanks, I wouldn't have thought of this. It seems Daniel Dadap did a patch series to do just that, in a generic way: https://lore.kernel.org/amd-gfx/20200727205357.27839-1-ddadap@xxxxxxxxxx/ I've tried patch 1 & 2, and after a fix[1] was able to call the _DDC method on most devices, but without any EDID being returned. I looked at the disassembled ACPI tables[2], and could not find any device with the _DDC method. Are you sure it's the only method the Windows driver uses to get the EDID ? Regards, Anisse [1] _DOD ids should only use 16 lower bits, see table here: https://uefi.org/specs/ACPI/6.4/Apx_B_Video_Extensions/display-specific-methods.html#dod-enumerate-all-devices-attached-to-the-display-adapter [2] acpidump: https://gitlab.freedesktop.org/drm/intel/-/issues/3454#note_913970 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx