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

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

[Mario Limonciello]

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.

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.

The first patch introduces the helper. The second fixes the AMDGPU
regression.

Mario Limonciello (2):
  drm/edid: Add an override-only EDID reader
  drm/amd/display: Honor EDID overrides for connected sinks

 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 14 +++++++-----
 drivers/gpu/drm/drm_edid.c                    | 22 +++++++++++++++++++
 include/drm/drm_edid.h                        |  1 +
 3 files changed, 32 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH 1/2] drm/edid: Add an override-only EDID reader

[Mario Limonciello]

The existing EDID read helpers retain a DDC presence probe before they
consult debugfs or firmware overrides. This is necessary for drivers that
use a successful EDID read as connector-presence evidence.

Drivers with independent presence detection cannot retrieve an override
when DDC is unresponsive.

Add drm_edid_read_override() so those drivers can retrieve a configured
override without probing hardware. Keep DRM_FORCE_OFF semantics and the
existing debugfs-before-firmware priority.

Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/gpu/drm/drm_edid.c | 22 ++++++++++++++++++++++
 include/drm/drm_edid.h     |  1 +
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3148038747b6e..4857bcae5e117 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2289,6 +2289,28 @@ static const struct drm_edid *drm_edid_override_get(struct drm_connector *connec
 	return IS_ERR(override) ? NULL : override;
 }
 
+/**
+ * drm_edid_read_override - read override or firmware EDID
+ * @connector: connector to use
+ *
+ * Read the EDID from debugfs override_edid or firmware EDID
+ * (drm_edid_load_firmware() and drm.edid_firmware parameter), in this priority
+ * order. This does not probe the connector or read the EDID from hardware.
+ *
+ * The returned pointer must be freed using drm_edid_free().
+ *
+ * Return: Pointer to EDID, or NULL if the connector is forced off or no EDID
+ * override is available.
+ */
+const struct drm_edid *drm_edid_read_override(struct drm_connector *connector)
+{
+	if (connector->force == DRM_FORCE_OFF)
+		return NULL;
+
+	return drm_edid_override_get(connector);
+}
+EXPORT_SYMBOL(drm_edid_read_override);
+
 /* For debugfs edid_override implementation */
 int drm_edid_override_show(struct drm_connector *connector, struct seq_file *m)
 {
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index a2617aa34edfc..cdd874b98340d 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -469,6 +469,7 @@ const struct drm_edid *drm_edid_dup(const struct drm_edid *drm_edid);
 void drm_edid_free(const struct drm_edid *drm_edid);
 bool drm_edid_valid(const struct drm_edid *drm_edid);
 const struct edid *drm_edid_raw(const struct drm_edid *drm_edid);
+const struct drm_edid *drm_edid_read_override(struct drm_connector *connector);
 const struct drm_edid *drm_edid_read(struct drm_connector *connector);
 const struct drm_edid *drm_edid_read_ddc(struct drm_connector *connector,
 					 struct i2c_adapter *adapter);
-- 
2.43.0

[PATCH 2/2] drm/amd/display: Honor EDID overrides for connected sinks

[Mario Limonciello]

Display Core determines whether a digital sink is physically connected
from HPD before dm_helpers_read_local_edid() attempts to acquire its EDID.

The helper currently calls drm_edid_read_ddc(). For an unforced connector,
that function probes DDC before consulting a debugfs or firmware override.
If a present sink stops responding over DDC, the probe returns early. The
configured override is ignored, and AMDGPU creates a 640x480 fallback mode.
That also prevents DRM's later override fallback from running.

Read an explicit override before trying ACPI, VBIOS, or DDC sources. Since
DC has already established physical presence, this does not make the EDID
override force a disconnected connector on. The existing successful-read
path updates the DRM connector and copies and parses the EDID into dc_sink,
keeping DRM and Display Core state synchronized.

Fixes: 7c7f5b15be65 ("drm/amd/display: Refactor edid read.")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5779
Cc: stable@vger.kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index d451082552e83..b8f02c854667e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -1244,12 +1244,16 @@ enum dc_edid_status dm_helpers_read_local_edid(
 	 * do check sum and retry to make sure read correct edid.
 	 */
 	do {
-		drm_edid = dm_helpers_read_acpi_edid(aconnector);
-		if (drm_edid)
-			drm_info(connector->dev, "Using ACPI provided EDID for %s\n", connector->name);
-		else if (!ddc)
+		drm_edid = drm_edid_read_override(connector);
+		if (!drm_edid) {
+			drm_edid = dm_helpers_read_acpi_edid(aconnector);
+			if (drm_edid)
+				drm_info(connector->dev, "Using ACPI provided EDID for %s\n",
+					 connector->name);
+		}
+		if (!drm_edid && !ddc)
 			drm_edid = dm_helpers_read_vbios_hardcoded_edid(link, aconnector);
-		else
+		else if (!drm_edid)
 			drm_edid = drm_edid_read_ddc(connector, ddc);
 		drm_edid_connector_update(connector, drm_edid);
 
-- 
2.43.0

Re: [PATCH 2/2] drm/amd/display: Honor EDID overrides for connected sinks

[Harry Wentland]

On 2026-09-17 09:59, Mario Limonciello wrote:
> Display Core determines whether a digital sink is physically connected
> from HPD before dm_helpers_read_local_edid() attempts to acquire its EDID.
> 
> The helper currently calls drm_edid_read_ddc(). For an unforced connector,
> that function probes DDC before consulting a debugfs or firmware override.
> If a present sink stops responding over DDC, the probe returns early. The
> configured override is ignored, and AMDGPU creates a 640x480 fallback mode.
> That also prevents DRM's later override fallback from running.
> 
> Read an explicit override before trying ACPI, VBIOS, or DDC sources. Since
> DC has already established physical presence, this does not make the EDID
> override force a disconnected connector on. The existing successful-read
> path updates the DRM connector and copies and parses the EDID into dc_sink,
> keeping DRM and Display Core state synchronized.
> 
> Fixes: 7c7f5b15be65 ("drm/amd/display: Refactor edid read.")
> Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5779
> Cc: stable@vger.kernel.org
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>

Reviewed-by: Harry Wentland <harry.wentland@amd.com>

Harry

> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index d451082552e83..b8f02c854667e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -1244,12 +1244,16 @@ enum dc_edid_status dm_helpers_read_local_edid(
>  	 * do check sum and retry to make sure read correct edid.
>  	 */
>  	do {
> -		drm_edid = dm_helpers_read_acpi_edid(aconnector);
> -		if (drm_edid)
> -			drm_info(connector->dev, "Using ACPI provided EDID for %s\n", connector->name);
> -		else if (!ddc)
> +		drm_edid = drm_edid_read_override(connector);
> +		if (!drm_edid) {
> +			drm_edid = dm_helpers_read_acpi_edid(aconnector);
> +			if (drm_edid)
> +				drm_info(connector->dev, "Using ACPI provided EDID for %s\n",
> +					 connector->name);
> +		}
> +		if (!drm_edid && !ddc)
>  			drm_edid = dm_helpers_read_vbios_hardcoded_edid(link, aconnector);
> -		else
> +		else if (!drm_edid)
>  			drm_edid = drm_edid_read_ddc(connector, ddc);
>  		drm_edid_connector_update(connector, drm_edid);
>  

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

[Jani Nikula]

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.


BR,
Jani.


>
> The first patch introduces the helper. The second fixes the AMDGPU
> regression.
>
> Mario Limonciello (2):
>   drm/edid: Add an override-only EDID reader
>   drm/amd/display: Honor EDID overrides for connected sinks
>
>  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 14 +++++++-----
>  drivers/gpu/drm/drm_edid.c                    | 22 +++++++++++++++++++
>  include/drm/drm_edid.h                        |  1 +
>  3 files changed, 32 insertions(+), 5 deletions(-)

-- 
Jani Nikula, Intel

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

[Mario Limonciello]

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?

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).

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

[Jani Nikula]

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

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

[Mario Limonciello]

On 10/7/26 09:10, Jani Nikula wrote:
> 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.
> 

Take a look at the approach I came up with and see what you think.

https://lore.kernel.org/dri-devel/20261005194546.1712792-1-mario.limonciello@amd.com/

> 
>>
>> 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).
>