Le Wed, Jul 07, 2021 at 02:57:47PM -0500, Daniel Dadap a écrit : > On 6/1/21 5:43 PM, Anisse Astier wrote: > > > > 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 ? > > > _DDC only works on devices that actually implement it, and the vast majority > of devices don't, because the display just provides an EDID normally. AIUI, > usually a device will implement _DDC either because an embedded panel has no > ROM of its own to deliver an EDID, or to allow the EDID to be read by either > GPU on a system with a muxed display, regardless of which GPU happens to > have the DDC lines (in TMDS) or DP AUX routed to it at the moment. (To my > knowledge, nobody actually muxes DP AUX independently from the main link, > but there were some older pre-DP designs where DDC could be muxed > independently.) > > I'm not sure whether the comment about Windows using _DDC was meant for this > device in particular, or just more generally, since DDC is part of the ACPI > spec and some Windows GPU drivers *do* use it, where available. If it was > meant for a particular device, then it's possible that the ACPI tables > advertise different methods depending on e.g. _OSI. If you haven't already > tried doing so, it might be worth overriding _OSI to spoof Windows, to see > if _DDC gets advertised. I think it's already the default Linux behaviour according to https://www.kernel.org/doc/html/latest/firmware-guide/acpi/osi.html I added a few specific Windows versions (2007 - 2020), but did not see any difference. > > I'm not sure how you were able to call _DDC without an EDID being returned > as described above, if there was no _DDC method in the ACPI tables; I would > expect that attempting to call _DDC would fail to locate a suitable method > and do_acpi_ddc would return NULL. I wasn't, I just tried calling the method on all devices (removing the _DOD id check), but obviously it failed because it did not exist. > > > > 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 > > > Thanks; I don't see a version of your modified patch here, was the fix just > to mask the _DOD IDs against 0xffff? Yes, nothing fancy: - if (adr == dod_entries[i]) { + if (adr == (dod_entries[i] & 0xFFFF) ) { Regards, Anisse
