Re: [PATCH 0/2] drm/edid: Honor overrides when DDC is unresponsive

[Jani Nikula <jani.nikula@linux.intel.com>]

On Sat, 19 Sep 2026, Mario Limonciello <mario.limonciello@amd.com> wrote:
> On 9/18/26 04:41, Jani Nikula wrote:
>> On Thu, 17 Sep 2026, Mario Limonciello <mario.limonciello@amd.com> 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