Re: Native DisplayID support in core DRM

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

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