On Sat, 19 Sep 2026, Mario Limonciello <[email protected]> wrote: > On 9/18/26 04:41, Jani Nikula wrote: >> On Thu, 17 Sep 2026, Mario Limonciello <[email protected]> wrote: >>> DRM's EDID read helpers probe DDC before consulting debugfs or firmware >>> overrides. This preserves connector-detection semantics for drivers that >>> use a successful EDID read as evidence that a sink is connected, but it >>> prevents drivers with independent presence detection from using an >>> override when DDC is unresponsive. >> >> IOW, your use case is that you want to use an override EDID with >> reliable presence detection other than the DDC probe, and don't want to >> use connector forcing. >> >>> This affects AMD Display Core, which establishes physical presence from >>> HPD before attempting to read the EDID. When a connected sink stops >>> responding over DDC, the configured override is ignored and AMDGPU falls >>> back to a 640x480 mode. >>> >>> Add an override-only EDID reader that does not access hardware, then use >>> it in AMD Display Core before trying ACPI, VBIOS, or DDC sources. The new >>> helper preserves DRM_FORCE_OFF handling and the existing preference for >>> debugfs overrides over firmware EDIDs. >> >> It was quite a bit of work to unify the firmware/override EDID handling >> to be the same for all drivers. I'm not exactly thrilled about exposing >> a mechanism to *only* get the override EDID, just to allow drivers to >> deviate from the unified mechanisms. >> >> The goal was to plug in the override at the low level, hidden away from >> drivers, to make it as close to the normal case as possible. One of the >> follow-up ideas, which I never really got around to, was to do the exact >> same validity checking in _drm_do_get_edid() for override EDIDs as >> regular EDIDs. >> >> I'm thinking maybe we need a way to allow drivers to define a >> drm_probe_ddc() alternative as a connector callback? If you set it, you >> can use another mechanism for presence detection than DDC probe, >> otherwise fall back to DDC probe. It could be used in the regular case >> too, if you have a reliable and quicker mechanism than DDC probe. >> > Well I guess the real reason that this deviation in amdgpu exists is > because of the ability to read the EDID from ACPI. > > See dm_helpers_probe_acpi_edid() for what it does. Should we bump that > up to DRM core so all drivers could use it?
I guess would be nice to make it generic, but I'm not sure how many places might break. Maybe some of our cases might get fixed! ;D I wonder if it could be opt-in in the connector? BR, Jani. > > It was added to admgpu for consistency with Windows behavior - Windows > pulls from ACPI first. > > But if there isn't appettite for this being used everywhere; yeah maybe > switching to a callback might work too (I haven't prototyped it yet). -- Jani Nikula, Intel
