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
- 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)
- Install to
/usr/lib/firmware/edid/ and include in initramfs
- Add kernel parameters:
drm.edid_firmware=DP-2:edid/custom.bin video=DP-2:e
- 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
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:ewith a custom EDID loaded throughdrm.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 theHDR_OUTPUT_METADATA,Colorspace, andmax_bpcDRM 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-drmthat there are zero matches forHDR_OUTPUT_METADATA,Colorspace, ormax_bpcacross 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_firmwareapproach 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
/usr/lib/firmware/edid/and include in initramfsdrm.edid_firmware=DP-2:edid/custom.bin video=DP-2:eExpected behavior
The connector should expose
HDR_OUTPUT_METADATA,Colorspace, andmax_bpcproperties when the EDID declares HDR capability, even on force-enabled connectors with no physical sink.Actual behavior
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
HDR: disabled(capable) based on the EDID, butkscreen-doctor output.DP-2.hdr.enablefails with "The driver rejected the output configuration"