Native DisplayID support in core DRM

Native DisplayID support in core DRM

[Vidith Madhu]

Hi all,
I would like to inquire about adding native DisplayID support to core DRM. 
Native DisplayID is the anticipated successor to EDID for display metadata reporting. 
DisplayID is already available as an EDID extension block and is widely 
used by newer monitors and eDP notebook panels. Native DisplayID was
officially introduced rather recently in DisplayID 2.1 (Nov 2021) and 
requires reading the DisplayID structure directly over i2c/DDC in a 
similar fashion to EDID. Overall, the native DisplayID structure/data 
blocks are the same as the DisplayID2.1 EDID extension, but there are some 
specific requirements for what sinks must populate in the native
structure, due to the lack of an EDID base block.

While no consumer displays currently utilize native DisplayID, beginning  
this year VESA has mandated it be supported for new DP2.1 source device 
certification submissions. Therefore, display certification
on Linux is the most pressing motivation for native DisplayID support. 
Beyond that, ensuring this support is present by the time consumer 
displays start adopting it will provide a seamless consumer experience for all Linux
display driver vendors, including NVIDIA.

Here are some issues I have identified in core DRM that need to be 
considered for native DisplayID support:
    1. A mechanism for reading and validating native DisplayID needs to be 
       added. EDID reads in amdgpu and i915 appear to leverage 
       drm_edid_read_ddc() -> drm_do_probe_ddc_edid(), and _drm_do_get_edid() for
       validation. These utilities are all supplied through core DRM. Similar
       functions should exist for native DisplayID.

    2. drm_edid_info needs to be updated to support a native DisplayID 2.1  
       structure (i.e. have a drm_edid_info::displayid in addition to 
       drm_edid_info::edid, perhaps in a union). To do this, I think we 
       first need to maintain the full layout of a DID2.1 structure. 
       Currently, in drm_displayid_internal.h, there are a few block structs
       present (e.g. displayid_tiled_block,  displayid_formula_ timing_block,
       displayid_detailed_timing_block), but there are several more data 
       block types in DID2.1 that may be relevant if no EDID base block is
       present (e.g. Product Identification Data Block for name, manuf. data,
       serial number, etc).
       Also, drm_connector should have some way to indicate that its edid_blob_ptr
       contains DisplayID data.

    3. update_display_info() needs to handle the case where native DisplayID is
       being used. All of the fields of drm_display_info that are being 
       populated from the EDID will need to be accordingly updated.
       This includes the EDID extension work in drm_parse_cea_ext() and drm_edid_to_eld().
       In addition, _drm_edid_connector_add_modes() will need to just parse the 
       displayid timing blocks (already being done today from the EDID 
       extension).

    4. There is also the question of how the user interfaces for overriding and reading
       EDID will need to change (/sys/class/drm/cardX/edid and /lib/firmware). Should there
       be separate nodes for native DisplayID, or should they just deal with an opaque blob
       of bytes, and leave it up to the user/DRM to interpret whether it is EDID or native
       DisplayID?

We are rolling out native DisplayID support in the NVIDIA Linux drivers in an upcoming
release; we have implemented our own reading/parsing and are able to populate 
drm_connector::probed_modes with native DisplayID supplied modes. However, 
due to the current gaps, we are unable to populate drm_connector::edid_blob_ptr if
native DisplayID is being used, which leads to inconsistent state.


Would like to hear any thoughts on this topic, or if there is a roadmap from any in-tree
vendors to add this support.

Thanks,
Vidith

Re: Native DisplayID support in core DRM

[Ville Syrjälä]

On Mon, Apr 20, 2026 at 02:51:18PM -0500, Vidith Madhu wrote:
> Hi all,

Exposing the native DisplayID blob will need userspace support as well.
CCing some folks...

I think if people want to implement this before actual displays are
available then what would be needed are some reasonable sample
DisplayIDs so that the code can actually be tested.

> I would like to inquire about adding native DisplayID support to core DRM. 
> Native DisplayID is the anticipated successor to EDID for display metadata reporting. 
> DisplayID is already available as an EDID extension block and is widely 
> used by newer monitors and eDP notebook panels. Native DisplayID was
> officially introduced rather recently in DisplayID 2.1 (Nov 2021) and 
> requires reading the DisplayID structure directly over i2c/DDC in a 
> similar fashion to EDID. Overall, the native DisplayID structure/data 
> blocks are the same as the DisplayID2.1 EDID extension, but there are some 
> specific requirements for what sinks must populate in the native
> structure, due to the lack of an EDID base block.
> 
> While no consumer displays currently utilize native DisplayID, beginning  
> this year VESA has mandated it be supported for new DP2.1 source device 
> certification submissions. Therefore, display certification
> on Linux is the most pressing motivation for native DisplayID support. 
> Beyond that, ensuring this support is present by the time consumer 
> displays start adopting it will provide a seamless consumer experience for all Linux
> display driver vendors, including NVIDIA.
> 
> Here are some issues I have identified in core DRM that need to be 
> considered for native DisplayID support:
>     1. A mechanism for reading and validating native DisplayID needs to be 
>        added. EDID reads in amdgpu and i915 appear to leverage 
>        drm_edid_read_ddc() -> drm_do_probe_ddc_edid(), and _drm_do_get_edid() for
>        validation. These utilities are all supplied through core DRM. Similar
>        functions should exist for native DisplayID.
> 
>     2. drm_edid_info needs to be updated to support a native DisplayID 2.1  
>        structure (i.e. have a drm_edid_info::displayid in addition to 
>        drm_edid_info::edid, perhaps in a union). To do this, I think we 
>        first need to maintain the full layout of a DID2.1 structure. 
>        Currently, in drm_displayid_internal.h, there are a few block structs
>        present (e.g. displayid_tiled_block,  displayid_formula_ timing_block,
>        displayid_detailed_timing_block), but there are several more data 
>        block types in DID2.1 that may be relevant if no EDID base block is
>        present (e.g. Product Identification Data Block for name, manuf. data,
>        serial number, etc).
>        Also, drm_connector should have some way to indicate that its edid_blob_ptr
>        contains DisplayID data.
> 
>     3. update_display_info() needs to handle the case where native DisplayID is
>        being used. All of the fields of drm_display_info that are being 
>        populated from the EDID will need to be accordingly updated.
>        This includes the EDID extension work in drm_parse_cea_ext() and drm_edid_to_eld().
>        In addition, _drm_edid_connector_add_modes() will need to just parse the 
>        displayid timing blocks (already being done today from the EDID 
>        extension).
> 
>     4. There is also the question of how the user interfaces for overriding and reading
>        EDID will need to change (/sys/class/drm/cardX/edid and /lib/firmware). Should there
>        be separate nodes for native DisplayID, or should they just deal with an opaque blob
>        of bytes, and leave it up to the user/DRM to interpret whether it is EDID or native
>        DisplayID?
> 
> We are rolling out native DisplayID support in the NVIDIA Linux drivers in an upcoming
> release; we have implemented our own reading/parsing and are able to populate 
> drm_connector::probed_modes with native DisplayID supplied modes. However, 
> due to the current gaps, we are unable to populate drm_connector::edid_blob_ptr if
> native DisplayID is being used, which leads to inconsistent state.
> 
> 
> Would like to hear any thoughts on this topic, or if there is a roadmap from any in-tree
> vendors to add this support.
> 
> Thanks,
> Vidith

-- 
Ville Syrjälä
Intel

Re: Native DisplayID support in core DRM

[Vidith Madhu]

Thanks,
I agree with sample blobs being required for testing. DP2.1 CTS display analyzers provide this (what we used for our testing), but I understand that may not be a
feasible option especially for userspace developers. It might be possible to hack together some samples by harvesting DisplayID2.0 EDID extensions and adding any
necessary data based on the spec requirements.
Thanks,
Vidith

________________________________________
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Sent: Monday, April 20, 2026 3:16 PM
To: Vidith Madhu
Cc: dri-devel@lists.freedesktop.org; wayland-devel@lists.freedesktop.org; Simon Ser; xorg-devel@lists.x.org
Subject: Re: Native DisplayID support in core DRM

External email: Use caution opening links or attachments


On Mon, Apr 20, 2026 at 02:51:18PM -0500, Vidith Madhu wrote:
> Hi all,

Exposing the native DisplayID blob will need userspace support as well.
CCing some folks...

I think if people want to implement this before actual displays are
available then what would be needed are some reasonable sample
DisplayIDs so that the code can actually be tested.

> I would like to inquire about adding native DisplayID support to core DRM.
> Native DisplayID is the anticipated successor to EDID for display metadata reporting.
> DisplayID is already available as an EDID extension block and is widely
> used by newer monitors and eDP notebook panels. Native DisplayID was
> officially introduced rather recently in DisplayID 2.1 (Nov 2021) and
> requires reading the DisplayID structure directly over i2c/DDC in a
> similar fashion to EDID. Overall, the native DisplayID structure/data
> blocks are the same as the DisplayID2.1 EDID extension, but there are some
> specific requirements for what sinks must populate in the native
> structure, due to the lack of an EDID base block.
>
> While no consumer displays currently utilize native DisplayID, beginning
> this year VESA has mandated it be supported for new DP2.1 source device
> certification submissions. Therefore, display certification
> on Linux is the most pressing motivation for native DisplayID support.
> Beyond that, ensuring this support is present by the time consumer
> displays start adopting it will provide a seamless consumer experience for all Linux
> display driver vendors, including NVIDIA.
>
> Here are some issues I have identified in core DRM that need to be
> considered for native DisplayID support:
>     1. A mechanism for reading and validating native DisplayID needs to be
>        added. EDID reads in amdgpu and i915 appear to leverage
>        drm_edid_read_ddc() -> drm_do_probe_ddc_edid(), and _drm_do_get_edid() for
>        validation. These utilities are all supplied through core DRM. Similar
>        functions should exist for native DisplayID.
>
>     2. drm_edid_info needs to be updated to support a native DisplayID 2.1
>        structure (i.e. have a drm_edid_info::displayid in addition to
>        drm_edid_info::edid, perhaps in a union). To do this, I think we
>        first need to maintain the full layout of a DID2.1 structure.
>        Currently, in drm_displayid_internal.h, there are a few block structs
>        present (e.g. displayid_tiled_block,  displayid_formula_ timing_block,
>        displayid_detailed_timing_block), but there are several more data
>        block types in DID2.1 that may be relevant if no EDID base block is
>        present (e.g. Product Identification Data Block for name, manuf. data,
>        serial number, etc).
>        Also, drm_connector should have some way to indicate that its edid_blob_ptr
>        contains DisplayID data.
>
>     3. update_display_info() needs to handle the case where native DisplayID is
>        being used. All of the fields of drm_display_info that are being
>        populated from the EDID will need to be accordingly updated.
>        This includes the EDID extension work in drm_parse_cea_ext() and drm_edid_to_eld().
>        In addition, _drm_edid_connector_add_modes() will need to just parse the
>        displayid timing blocks (already being done today from the EDID
>        extension).
>
>     4. There is also the question of how the user interfaces for overriding and reading
>        EDID will need to change (/sys/class/drm/cardX/edid and /lib/firmware). Should there
>        be separate nodes for native DisplayID, or should they just deal with an opaque blob
>        of bytes, and leave it up to the user/DRM to interpret whether it is EDID or native
>        DisplayID?
>
> We are rolling out native DisplayID support in the NVIDIA Linux drivers in an upcoming
> release; we have implemented our own reading/parsing and are able to populate
> drm_connector::probed_modes with native DisplayID supplied modes. However,
> due to the current gaps, we are unable to populate drm_connector::edid_blob_ptr if
> native DisplayID is being used, which leads to inconsistent state.
>
>
> Would like to hear any thoughts on this topic, or if there is a roadmap from any in-tree
> vendors to add this support.
>
> Thanks,
> Vidith

--
Ville Syrjälä
Intel

Re: Native DisplayID support in core DRM

[Jani Nikula]

On Mon, 20 Apr 2026, Vidith Madhu <vmadhu@nvidia.com> wrote:
> Hi all,
> I would like to inquire about adding native DisplayID support to core DRM. 
> Native DisplayID is the anticipated successor to EDID for display metadata reporting. 
> DisplayID is already available as an EDID extension block and is widely 
> used by newer monitors and eDP notebook panels. Native DisplayID was
> officially introduced rather recently in DisplayID 2.1 (Nov 2021) and 
> requires reading the DisplayID structure directly over i2c/DDC in a 
> similar fashion to EDID. Overall, the native DisplayID structure/data 
> blocks are the same as the DisplayID2.1 EDID extension, but there are some 
> specific requirements for what sinks must populate in the native
> structure, due to the lack of an EDID base block.
>
> While no consumer displays currently utilize native DisplayID, beginning  
> this year VESA has mandated it be supported for new DP2.1 source device 
> certification submissions. Therefore, display certification
> on Linux is the most pressing motivation for native DisplayID support. 
> Beyond that, ensuring this support is present by the time consumer 
> displays start adopting it will provide a seamless consumer experience for all Linux
> display driver vendors, including NVIDIA.

By far the biggest hurdle in implementing native DisplayID support in
its own DDC address is exactly the "support" in current consumer
displays.

The specs say try the DisplayID DDC address first, and if there's
something, use it, otherwise fall back to EDID DDC address. At some
point in time I experimented with this in our CI, and the results
weren't encouraging.

Some displays return zeros or garbage, some lead to errors, some have
plain old EDID in the DisplayID DDC address. There might have been a
display that indeed had native DisplayID, not sure. But the point is,
the existing display behaviour make this fallback to plain old EDID is
going to be a bit tricky.

Some thoughts on implementation details below.

> Here are some issues I have identified in core DRM that need to be 
> considered for native DisplayID support:
>     1. A mechanism for reading and validating native DisplayID needs to be 
>        added. EDID reads in amdgpu and i915 appear to leverage 
>        drm_edid_read_ddc() -> drm_do_probe_ddc_edid(), and _drm_do_get_edid() for
>        validation. These utilities are all supplied through core DRM. Similar
>        functions should exist for native DisplayID.

No.

The exact same EDID functions should handle native DisplayID under the
hood, with no variation in drivers. The native DisplayID structure
contents should be stored in the (intentionally) opaque struct drm_edid.

IMO it would be a massive mistake to expose interfaces to let drivers do
this wrong in many different ways. One of the reasons is the old display
behaviour explained above.

>     2. drm_edid_info needs to be updated to support a native DisplayID 2.1  

There is no drm_edid_info. Maybe you're talking about struct drm_edid?

>        structure (i.e. have a drm_edid_info::displayid in addition to 
>        drm_edid_info::edid, perhaps in a union). To do this, I think we 
>        first need to maintain the full layout of a DID2.1 structure. 
>        Currently, in drm_displayid_internal.h, there are a few block structs
>        present (e.g. displayid_tiled_block,  displayid_formula_ timing_block,
>        displayid_detailed_timing_block), but there are several more data 
>        block types in DID2.1 that may be relevant if no EDID base block is
>        present (e.g. Product Identification Data Block for name, manuf. data,
>        serial number, etc).

struct drm_edid should contain a displayid member in addition to the
edid member, both as pointers to the blob that's read from DDC. struct
drm_edid should not contain parsed data, but rather the raw data.

>        Also, drm_connector should have some way to indicate that its edid_blob_ptr
>        contains DisplayID data.

I fear having the current EDID blob property only contain the native
DisplayID might amount to an ABI breakage. It all depends on how robust
the userspace handling of the data is. We might have to have a separate
blob for DisplayID.

It might be nice to read both the DisplayID and the EDID from the
display, and expose the EDID to userspace for backward
compatibility. However, I think reading the EDID when DisplayID is
present goes against the VESA spec.

>     3. update_display_info() needs to handle the case where native DisplayID is
>        being used. All of the fields of drm_display_info that are being 
>        populated from the EDID will need to be accordingly updated.
>        This includes the EDID extension work in drm_parse_cea_ext() and drm_edid_to_eld().
>        In addition, _drm_edid_connector_add_modes() will need to just parse the 
>        displayid timing blocks (already being done today from the EDID 
>        extension).

For example the CTA data block iterators in drm_edid.c already go
through both EDID and DisplayID. The DisplayID iterators just need to be
amended to handle native DisplayID in addition to DisplayID in EDID
extension.

>
>     4. There is also the question of how the user interfaces for overriding and reading
>        EDID will need to change (/sys/class/drm/cardX/edid and /lib/firmware). Should there
>        be separate nodes for native DisplayID, or should they just deal with an opaque blob
>        of bytes, and leave it up to the user/DRM to interpret whether it is EDID or native
>        DisplayID?

Per spec only one or the other should be used at a time. I think
firmware EDID and debugfs EDID override could be extended to handle
native DisplayID as well... though if we want to expose both to
userspace, might be cleaner to have them separate. This needs to be
thought out.

> We are rolling out native DisplayID support in the NVIDIA Linux drivers in an upcoming
> release; we have implemented our own reading/parsing and are able to populate 
> drm_connector::probed_modes with native DisplayID supplied modes. However, 
> due to the current gaps, we are unable to populate drm_connector::edid_blob_ptr if
> native DisplayID is being used, which leads to inconsistent state.
>
>
> Would like to hear any thoughts on this topic, or if there is a roadmap from any in-tree
> vendors to add this support.

You could always join the party, and submit your work upstream.


BR,
Jani.


-- 
Jani Nikula, Intel

Re: Native DisplayID support in core DRM

[Simon Ser]

On Monday, April 20th, 2026 at 22:16, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> I think if people want to implement this before actual displays are
> available then what would be needed are some reasonable sample
> DisplayIDs so that the code can actually be tested.

Yeah. The spec has a few examples, but some real-world blobs would be very
useful. I'd be interested in writing/reviewing DisplayID patches for
libdisplay-info and wlroots.

We have some DisplayID parsing in libdisplay-info, but we don't provide yet
a way to parse raw DisplayID blobs, short of a real use-case. We've designed
the API in such a way that DisplayID support can be easily added, though.

> > While no consumer displays currently utilize native DisplayID, beginning
> > this year VESA has mandated it be supported for new DP2.1 source device
> > certification submissions. Therefore, display certification
> > on Linux is the most pressing motivation for native DisplayID support.
> > Beyond that, ensuring this support is present by the time consumer
> > displays start adopting it will provide a seamless consumer experience for all Linux
> > display driver vendors, including NVIDIA.

That's good to hear.

> >     4. There is also the question of how the user interfaces for overriding and reading
> >        EDID will need to change (/sys/class/drm/cardX/edid and /lib/firmware). Should there
> >        be separate nodes for native DisplayID, or should they just deal with an opaque blob
> >        of bytes, and leave it up to the user/DRM to interpret whether it is EDID or native
> >        DisplayID?

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.

Simon

Re: Native DisplayID support in core DRM

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

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

Re: Native DisplayID support in core DRM

[Thomas Zimmermann]

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)