Skip to content

HDR DRM properties missing on force-enabled virtual connectors (video=:e) #1101

@HarryAnkers

Description

@HarryAnkers

NVIDIA Open GPU Kernel Modules Version

595.58.03

Does this happen with the proprietary driver?

Not tested - RTX 5080 (Blackwell) only supports open kernel modules.

Operating System and Version

CachyOS (Arch-based) rolling release

Kernel Release

6.19.11-1-cachyos

Hardware

GPU: NVIDIA GeForce RTX 5080

Describe the bug

When force-enabling a connector via video=DP-2:e with a custom EDID loaded through drm.edid_firmware=DP-2:edid/custom.bin, the connector correctly shows as connected and modes are enumerated from the EDID - including 4K@60/120, 1440p@120, etc. However, the connector is missing the HDR_OUTPUT_METADATA, Colorspace, and max_bpc DRM properties entirely.

The EDID includes a valid HDR Static Metadata Data Block (SMPTE ST 2084, ~1000 nits peak), Colorimetry Data Block (BT.2020), HDMI VSDB (max TMDS 600 MHz), and HDMI Forum VSDB (SCDC present). KDE Plasma sees the HDR capability and reports it as "disabled" (not "incapable"), but actually enabling HDR fails because the DRM properties don't exist on the connector.

I've confirmed with modetest -M nvidia-drm that there are zero matches for HDR_OUTPUT_METADATA, Colorspace, or max_bpc across all connectors when using force-enabled virtual displays.

The same GPU correctly exposes these properties when a real Samsung S95C TV is connected via HDMI - HDR works fine in that case. So the driver does support it, it just doesn't create the properties on force-enabled connectors.

Use case

This matters for headless game streaming with Sunshine/Moonlight on Linux. The video=:e + drm.edid_firmware approach is currently the only reliable way to get a virtual display working on NVIDIA without a dummy plug (and dummy plugs have their own bandwidth issues with DP link training). Everything works great - 4K@120, custom resolutions, KMS capture - except HDR, because the properties are missing.

Steps to reproduce

  1. Create a 256-byte EDID with a CTA-861-G extension containing HDR Static Metadata, HDMI VSDB, and HDMI Forum VSDB (I can share the generator script if useful)
  2. Install to /usr/lib/firmware/edid/ and include in initramfs
  3. Add kernel parameters: drm.edid_firmware=DP-2:edid/custom.bin video=DP-2:e
  4. Reboot with nothing physically connected to DP-2

Expected behavior

The connector should expose HDR_OUTPUT_METADATA, Colorspace, and max_bpc properties when the EDID declares HDR capability, even on force-enabled connectors with no physical sink.

Actual behavior

$ sudo modetest -M nvidia-drm 2>/dev/null | grep -c "HDR_OUTPUT_METADATA"
0
$ sudo modetest -M nvidia-drm 2>/dev/null | grep -c "max_bpc"  
0
$ sudo modetest -M nvidia-drm 2>/dev/null | grep -c "Colorspace"
0

The connector status, modes, EDID physical dimensions, and display name all update correctly from the firmware EDID. Only the HDR-related DRM properties are missing.

Additional context

  • Same behavior on both DP and HDMI connectors when force-enabled
  • KDE reports HDR: disabled (capable) based on the EDID, but kscreen-doctor output.DP-2.hdr.enable fails with "The driver rejected the output configuration"
  • Tested with the 595.58 Color Pipeline API preview driver
  • I wrote up the full virtual display setup as a guide: https://gist.github.com/HarryAnkers/8dbf551d66f00e8156ef4dd2b2b090a0

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions