Re: Native DisplayID support in core DRM

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 04.05.26 um 12:30 schrieb Jani Nikula:
> 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.

Is there a technical problem/side effect/interference from reading both?

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

IMHO we should

1) follow the spec and expose DisplayID first and EDID only if the 
former is not available, and
2) provide a kernel config option to provide both.

People building kernel usually have control over user space as well. 
That option can be enabled by anyone with a legacy user space. This also 
puts some mild pressure on user space to implement DisplayID.

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

Same here. DisplayID first and treat EDID as legacy.

Best regards
Thomas

>
> And what userspace does with all of this is a mess of its own...
>
>
> BR,
> Jani.
>
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)