On 10/7/26 09:10, Jani Nikula wrote:
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.
Take a look at the approach I came up with and see what you think.
https://lore.kernel.org/dri-devel/[email protected]/
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).
