Re: Native DisplayID support in core DRM

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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