Re: Native DisplayID support in core DRM

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

On Thu, 30 Apr 2026, Simon Ser <contact@emersion.fr> wrote:
> The big one here is the "EDID" blob property exposed by KMS. We can't just put
> a DisplayID blob in there, that would break user-space. We'll need a new
> property.

I think the big question is what do we do with the EDID property when we
encounter a display with native DisplayID.

The VESA E-DDC spec says the host should try DisplayID first, and not
read the EDID if a DisplayID is found. However, if we only update the
DisplayID property and not the EDID property, I think that'll be a
regression.

So maybe we need to read both DisplayID and EDID, contrary to what the
E-DDC spec says. Obviously that means slower detection overall, for all
displays, old and new. Especially if there are errors reading DisplayID,
which you'd expect with old displays.

There's an additional catch. The E-DDC spec says the capabilities in the
DisplayID don't need to be a strict superset of the capabilities in the
EDID. The idea is that the DisplayID is for new hosts, and the EDID is
for legacy and max interoperability. But if we read both and aim for no
regressions, we'll have to expose a union of the capabilities.

Strict adherence to spec isn't exactly what EDID is known for. We're
likely to encounter displays where the DisplayID and EDID contradict
each other, and we'll have to mediate between them.

And what userspace does with all of this is a mess of its own...


BR,
Jani.


-- 
Jani Nikula, Intel