All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Mario Limonciello <mario.limonciello@amd.com>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Cc: Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH 0/2] drm/edid: Honor overrides when DDC is unresponsive
Date: Fri, 18 Sep 2026 12:41:34 +0300	[thread overview]
Message-ID: <1efb1842489bc50e87ab0476e3d3ad861d6ef807@intel.com> (raw)
In-Reply-To: <20260917135949.2552704-1-mario.limonciello@amd.com>

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

  parent reply	other threads:[~2026-09-18  9:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17 13:59 [PATCH 0/2] drm/edid: Honor overrides when DDC is unresponsive Mario Limonciello
2026-09-17 13:59 ` [PATCH 1/2] drm/edid: Add an override-only EDID reader Mario Limonciello
2026-09-17 13:59 ` [PATCH 2/2] drm/amd/display: Honor EDID overrides for connected sinks Mario Limonciello
2026-09-17 20:26   ` Harry Wentland
2026-09-18  9:41 ` Jani Nikula [this message]
2026-09-19 17:04   ` [PATCH 0/2] drm/edid: Honor overrides when DDC is unresponsive Mario Limonciello
2026-10-07 14:10     ` Jani Nikula
2026-10-07 14:14       ` Mario Limonciello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1efb1842489bc50e87ab0476e3d3ad861d6ef807@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mario.limonciello@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.