Native DisplayID support in core DRM

[Vidith Madhu <vmadhu@nvidia.com>]

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