[PATCH 0/4] drm/amd: fix HDMI output with non-HDMI EDID overrides

[PATCH 0/4] drm/amd: fix HDMI output with non-HDMI EDID overrides

[Johannes Wüller]

This series fixes several issues that prevent amdgpu from driving an
HDMI display at its native resolution when a non-HDMI EDID is injected
via drm.edid_firmware or debugfs edid_override.

The motivating case is a Dell U3011 (2560x1600) connected via HDMI,
whose native HDMI EDID only advertises CEA modes up to 1920x1080. By
injecting the monitor's DisplayPort EDID (which contains the native
2560x1600 mode), the correct resolution becomes available. However,
amdgpu then fails to drive the output because the injected EDID lacks
an HDMI VSDB, causing the driver to treat the physical HDMI connector
as a passive HDMI-DVI dongle, and rejecting the required pixel clock.

Patch 1 adds an edid_overridden flag to drm_connector, set by the
existing EDID override mechanisms in _drm_do_get_edid(), so that
drivers can detect when an override is in effect and adjust their
behavior accordingly, without duplicating the override mechanism.

Patches 2-4 fix the amdgpu-specific issues:
- incorrect signal type selection when an override is active
- unconditional rejection of all colour depths when max_tmds_clock is
  zero
- force_yuv420/422_output flags being silently ignored when the
  display doesn't advertise the requested format.

Tested on AMD Ryzen 9 7950X (RDNA3 iGPU, DCN 3.1.5) with a Dell U3011
connected via HDMI at 2560x1600@60Hz RGB 8bpc, and another Dell U3011
connected via DisplayPort in the same mode.

This is my first code contribution to the kernel, so I would appreciate
feedback on whether I've gotten recipients and other procedural details
right! :)

Johannes Wüller (4):
  drm: add edid_overridden flag to drm_connector
  drm/amd: fix HDMI signal type for EDID overrides
  drm/amd: treat max_tmds_clock==0 as unconstrained
  drm/amd: fix force_yuv420/422_output being ignored

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 20 +++++++++++--------
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  9 ++++++++-
 drivers/gpu/drm/drm_edid.c                    |  2 ++
 include/drm/drm_connector.h                   |  8 ++++++++
 4 files changed, 30 insertions(+), 9 deletions(-)

-- 
2.53.0

[PATCH 1/4] drm: add edid_overridden flag to drm_connector

[Johannes Wüller]

When an EDID override is in effect, the physical connector may not
match reported capabilities. Adds a drm_connector flag that allows
drivers to detect such mismatches.

Signed-off-by: Johannes Wüller <johanneswueller@gmail.com>
---
 drivers/gpu/drm/drm_edid.c  | 2 ++
 include/drm/drm_connector.h | 8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 26bb7710a462..9b0f410ea2de 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2373,6 +2373,7 @@ static struct edid *_drm_do_get_edid(struct drm_connector *connector,
 	struct edid *edid, *new;
 	size_t alloc_size = EDID_LENGTH;
 
+	connector->edid_overridden = false;
 	override = drm_edid_override_get(connector);
 	if (override) {
 		alloc_size = override->size;
@@ -2380,6 +2381,7 @@ static struct edid *_drm_do_get_edid(struct drm_connector *connector,
 		drm_edid_free(override);
 		if (!edid)
 			return NULL;
+		connector->edid_overridden = true;
 		goto ok;
 	}
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index c18be8c19de0..43d7ac31deba 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2261,6 +2261,14 @@ struct drm_connector {
 	/** @bad_edid_counter: track sinks that give us an EDID with invalid checksum */
 	unsigned bad_edid_counter;
 
+	/**
+	 * @edid_overridden: Indicates whether the last read EDID was an
+	 * override (e.g. via debugfs edid_override or drm.edid_firmware kernel
+	 * parameter), which can cause the physical connector to differ from
+	 * the advertised capabilities.
+	 */
+	bool edid_overridden;
+
 	/**
 	 * @edid_corrupt: Indicates whether the last read EDID was corrupt. Used
 	 * in Displayport compliance testing - Displayport Link CTS Core 1.2
-- 
2.53.0

Claude review: drm: add edid_overridden flag to drm_connector

[Claude Code Review Bot]

Patch Review

**Approach concern:** The flag is set only inside `_drm_do_get_edid()`, which is the legacy EDID read path. While `drm_edid_read_ddc()` currently chains through `_drm_do_get_edid()`, this is an implementation detail that could change. A more robust approach would be to check at query time whether an override exists (e.g. via `drm_edid_override_get()` or checking `connector->edid_override`), rather than caching a flag that can become stale.

**Staleness risk:** The flag is set during EDID read, but nothing clears it if the override is removed between reads. If userspace removes an override via debugfs without triggering a new EDID read, `edid_overridden` remains `true`. The `connector->edid_overridden = false` at line 2376 only runs when `_drm_do_get_edid()` is called again.

**Missing Cc:** The patch modifies core DRM infrastructure but doesn't Cc `linux-kernel@vger.kernel.org` in the commit (though it is in the email headers from get_maintainer). More importantly, it would benefit from Cc'ing the DRM misc maintainers explicitly since this touches `drm_connector.h`.

**Naming:** `edid_overridden` is reasonable, but `edid_override_active` might be clearer since it describes current state rather than a past-tense event.

---
Generated by Claude Code Patch Reviewer

[PATCH 2/4] drm/amd: fix HDMI signal type for EDID overrides

[Johannes Wüller]

If an EDID override is in effect (e.g. via debugfs edid_override or
drm.edid_firmware kernel parameter), the overriding EDID may not
advertise capabilities matching the physical connector being used.
In that case, trust the physical connector type over the EDID in
create_eml_sink() and dm_helpers_parse_edid_caps().

Signed-off-by: Johannes Wüller <johanneswueller@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c        | 9 ++++++++-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c    | 9 ++++++++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ff09a5371cb2..bc853f7555a9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7911,7 +7911,14 @@ static void create_eml_sink(struct amdgpu_dm_connector *aconnector)
 		return;
 	}
 
-	if (connector->display_info.is_hdmi)
+	/*
+	 * If an EDID override is active, it may not advertise HDMI capability
+	 * even though the physical connector is HDMI. Trust the connector type.
+	 */
+	if (connector->display_info.is_hdmi ||
+	    (connector->edid_overridden &&
+	     (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+	      connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)))
 		init_params.sink_signal = SIGNAL_TYPE_HDMI_TYPE_A;
 
 	aconnector->drm_edid = drm_edid;
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 d7b0b84b3865..36b6e37f1517 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
@@ -137,7 +137,14 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
 				  edid_caps->display_name,
 				  AUDIO_INFO_DISPLAY_NAME_SIZE_IN_CHARS);
 
-	edid_caps->edid_hdmi = connector->display_info.is_hdmi;
+	/*
+	 * If an EDID override is active, it may not advertise HDMI capability
+	 * even though the physical connector is HDMI. Trust the connector type.
+	 */
+	edid_caps->edid_hdmi = connector->display_info.is_hdmi ||
+		(connector->edid_overridden &&
+		 (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+		  connector->connector_type == DRM_MODE_CONNECTOR_HDMIB));
 
 	if (edid_caps->edid_hdmi)
 		populate_hdmi_info_from_connector(&connector->display_info.hdmi, edid_caps);
-- 
2.53.0

Claude review: drm/amd: fix HDMI signal type for EDID overrides

[Claude Code Review Bot]

Patch Review

**Potential problem with `populate_hdmi_info_from_connector()`:** In `dm_helpers_parse_edid_caps()`, when the code forces `edid_caps->edid_hdmi = true` due to the override, it then calls:
```c
if (edid_caps->edid_hdmi)
    populate_hdmi_info_from_connector(&connector->display_info.hdmi, edid_caps);
```
But `connector->display_info.hdmi` was populated from the *overridden* EDID (which lacks HDMI VSDB). This means the HDMI info structure will contain zeros/defaults, which could lead to issues downstream (e.g. missing audio capabilities, incorrect infoframe data). The patch should document this limitation or handle it.

**Duplicated logic:** The connector-type check `(connector->connector_type == DRM_MODE_CONNECTOR_HDMIA || connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)` appears in two places. A small helper like `drm_connector_is_hdmi_type()` would reduce duplication, though this is minor.

**Signal type for HDMIB:** Setting `SIGNAL_TYPE_HDMI_TYPE_A` for `DRM_MODE_CONNECTOR_HDMIB` connectors is technically incorrect - HDMI Type B uses a different physical connector. In practice HDMIB is essentially unused, so this is unlikely to cause real issues, but it's worth noting.

---
Generated by Claude Code Patch Reviewer

[PATCH 3/4] drm/amd: treat max_tmds_clock==0 as unconstrained

[Johannes Wüller]

If max_tmds_clock is not specified by the EDID, it should be treated
as unconstrained rather than as a zero MHz limit, since it would cause
adjust_colour_depth_from_display_info() to reject all color depths
unconditionally.

Signed-off-by: Johannes Wüller <johanneswueller@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index bc853f7555a9..82c8dc8dd39f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6612,7 +6612,8 @@ static bool adjust_colour_depth_from_display_info(
 			/* The above depths are the only ones valid for HDMI. */
 			return false;
 		}
-		if (normalized_clk <= info->max_tmds_clock) {
+		if (info->max_tmds_clock == 0 ||
+		    normalized_clk <= info->max_tmds_clock) {
 			timing_out->display_color_depth = depth;
 			return true;
 		}
-- 
2.53.0

Claude review: drm/amd: treat max_tmds_clock==0 as unconstrained

[Claude Code Review Bot]

Patch Review

**This is the most straightforward and correct patch in the series.** When an EDID lacks an HDMI VSDB, `max_tmds_clock` will be 0. Treating 0 as "unlimited" rather than "no clock allowed" is the right fix, and matches how other drivers handle this (e.g. the DRM core's `drm_hdmi_compute_mode_clock()` treats 0 as unconstrained).

```c
if (info->max_tmds_clock == 0 ||
    normalized_clk <= info->max_tmds_clock) {
```

This is clean and correct. However, should this also be gated on `edid_overridden`? Without the override flag check, this changes behavior for any display that genuinely reports `max_tmds_clock == 0` through its real EDID, which could potentially allow modes that exceed the display's capabilities. That said, the HDMI spec says a conformant EDID should always include a VSDB with a valid max_tmds_clock if it supports HDMI, so 0 generally means "not specified" rather than "zero limit" — making this change safe regardless of override status.

---
Generated by Claude Code Patch Reviewer

[PATCH 4/4] drm/amd: fix force_yuv420/422_output being ignored

[Johannes Wüller]

force_yuv420_output and force_yuv422_output are intended to force a
specific pixel encoding. However, if the display doesn't advertise this
capability, the flag becomes ineffective.

Fix the flag to actually enforce the encoding, regardless of advertised
capabilities.

Signed-off-by: Johannes Wüller <johanneswueller@gmail.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 82c8dc8dd39f..9b298879de53 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6650,13 +6650,9 @@ static void fill_stream_properties_from_drm_display_mode(
 	if (drm_mode_is_420_only(info, mode_in)
 			&& stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
 		timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-	else if (drm_mode_is_420_also(info, mode_in)
-			&& aconnector
-			&& aconnector->force_yuv420_output)
+	else if (aconnector && aconnector->force_yuv420_output)
 		timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-	else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR422)
-			&& aconnector
-			&& aconnector->force_yuv422_output)
+	else if (aconnector && aconnector->force_yuv422_output)
 		timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR422;
 	else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR444)
 			&& stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
-- 
2.53.0

Claude review: drm/amd: fix force_yuv420/422_output being ignored

[Claude Code Review Bot]

Patch Review

**Correctness concern:** The original code gated `force_yuv420_output` on `drm_mode_is_420_also()` and `force_yuv422_output` on `DRM_COLOR_FORMAT_YCBCR422`. These guards existed to prevent forcing a pixel encoding the display genuinely cannot accept. Removing them means:

```c
else if (aconnector && aconnector->force_yuv420_output)
    timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
```

This will now force YCbCr 4:2:0 even for modes that are not 420-capable at all (not just "420_also" but completely 420-incompatible). This could cause a black screen or signal errors on displays that truly don't support 4:2:0 for a given mode.

The commit message frames this as "the flag becomes ineffective" when the display doesn't advertise the capability, but the `force_` prefix in the debugfs attribute does suggest "force regardless." Still, this is a user-facing behavior change that removes safety checks. It would be better to either:
1. Gate on `edid_overridden` (only bypass the check when an override is active), or
2. Add a warning log when forcing an unadvertised encoding so users can diagnose issues.

**Interaction with Patch 2:** This patch is listed as fixing issues with EDID overrides, but it unconditionally changes behavior for all displays, not just those with overrides. This seems like an overly broad change for the stated problem.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/amd: fix HDMI output with non-HDMI EDID overrides

[Claude Code Review Bot]

Overall Series Review

Subject: drm/amd: fix HDMI output with non-HDMI EDID overrides
Author: =?UTF-8?q?Johannes=20W=C3=BCller?= <johanneswueller@gmail.com>
Patches: 5
Reviewed: 2026-03-16T11:48:51.389884

---

This is a well-motivated 4-patch series that fixes a real usability problem: HDMI output fails when a non-HDMI EDID (e.g. DisplayPort EDID) is injected via `drm.edid_firmware` or debugfs `edid_override`. The series is well-structured, with clear commit messages and a logical progression. However, there are several design and correctness concerns, particularly around Patch 1's approach and Patch 2's interaction with `populate_hdmi_info_from_connector()`.

---
Generated by Claude Code Patch Reviewer