Parse DisplayID 2 HDR capabilities from panel EDID

[stappmus]

Summary

• parse HDR-relevant DisplayID 2.0 blocks from raw EDID extension bytes when CTA-derived HDR data is missing
• populate BT.2020 and PQ/HDR capability data for panels that advertise HDR through DisplayID 2.0 instead of CTA HDR blocks
• fix DisplayID v2 block offset handling while walking extension payloads

Problem

On an OLED panel reported as LG Display 0x07C5, the compositor runtime saw:

• parsedBT2020 = false
• parsedHDRMeta = false
• parsedPQ = false

even though edid-decode showed HDR-relevant capability data in DisplayID 2.0:

• BT.2020 support
• SMPTE ST 2084 / PQ support
• luminance information

Because of that, downstream Hyprland treated the panel as SDR-only and HDR could not activate.

Root cause

The existing EDID parsing path did not surface the relevant DisplayID 2.0 HDR capability information for this panel.

The tested panel exposes HDR-relevant data in DisplayID 2.0 blocks including:

• 0x21 for luminance information
• 0x26 for supported color space / EOTF combinations

Fix details

In src/backend/drm/DRM.cpp:

• add a DisplayID 2.0 block walk over raw extension bytes
• decode block 0x21 luminance data
• decode block 0x26 BT.2020 / PQ capability bits
• populate:
  • parsed.supportsBT2020
  • parsed.hdrMetadata
  • parsed.hdrMetadata->supportsPQ
• fix the payload start offset to begin after the full DisplayID v2 extension header

Validated outcome

After this fix, downstream Hyprland sees the panel as HDR-capable and can activate HDR correctly on the tested OLED panel.

Tested hardware

• Dell XPS 16 OLED
• internal panel LG Display 0x07C5

Notes

This change is intentionally additive: it fills in DisplayID 2.0 capability data when the existing CTA-derived path does not provide it.

[vaxerski]

use sc<> instead of static_cast