HDR always rejected on HDMI 3D-capable sinks (projectors) on Blackwell, although infoframes are not shared

Start with nvDpyIsHDRCapable() in src/nvidia-modeset/src/nvkms-dpy.c, then compare its HDMI 3D check with SendHDRInfoFrame() in nvkms-hdmi.c and the supportsGenericSharedInfoFrames capability. The report includes a proposed condition and says a patched module enabled HDR at 3840x2160@60; verify the atomic check and HDR behavior on a Blackwell GPU with an HDMI 3D capable sink.

NVIDIA Open GPU Kernel Modules Version

615.78.08

Operating System and Version

CachyOS (Arch Linux)

Kernel Release

7.2.10-1-cachyos

Hardware: GPU

GeForce RTX 5090 (GB202)

Describe the bug

HDR cannot be enabled on an HDMI projector (Hisense / Vidda C2 Ultra). Any atomic commit that sets the connector Colorspace to BT2020_RGB/BT2020_YCC fails in the driver check with -EINVAL (drm_atomic_check_only ... atomic driver check ... failed: -22), with no nvidia-drm or nvidia-modeset message, even with nvidia_modeset.debug=1. It fails at 3840x2160@60, 3840x2160@30 and 1920x1080@60, so it is not a link-bandwidth problem. The same projector, GPU, port and cable do HDR on Windows. The main monitor on DisplayPort does HDR on the same system.

Root cause: nvDpyIsHDRCapable() in src/nvidia-modeset/src/nvkms-dpy.c returns FALSE for every sink whose EDID advertises HDMI 3D:

/* XXX HDR is not supported with HDMI 3D due to both using VSI infoframes. */
if (pInfo->HDMI3DSupported) {
    return FALSE;
}

This projector really advertises 3D (HDMI VSDB byte c0: 3D_present=1, plus side-by-side / top-and-bottom / frame-packing), as almost every home-cinema projector does. But the reason given in the comment only applies to HALs without generic shared infoframes. SendHDRInfoFrame() in nvkms-hdmi.c already takes that into account and only skips the HDR infoframe for 3D sinks when !pDevEvo->caps.supportsGenericSharedInfoFrames. Blackwell (C9/CA/CB/CC) has supportsGenericSharedInfoFrames = 1, so the HDR infoframe and the VSI have separate slots there, yet nvDpyIsHDRCapable() still rejects HDR.

Fix (applies to 615.78.08), using the same condition as SendHDRInfoFrame():

--- a/src/nvidia-modeset/src/nvkms-dpy.c
+++ b/src/nvidia-modeset/src/nvkms-dpy.c
@@ -3921,9 +3921,12 @@
 
     /*
      * XXX HDR is not supported with HDMI 3D due to both using VSI
-     * infoframes.
+     * infoframes. This only applies when the HAL cannot send generic
+     * shared infoframes; otherwise the HDR and VSI infoframes use separate
+     * slots (see SendHDRInfoFrame()).
      */
-    if (pInfo->HDMI3DSupported) {
+    if (pInfo->HDMI3DSupported &&
+        !pDpyEvo->pDispEvo->pDevEvo->caps.supportsGenericSharedInfoFrames) {
         return FALSE;
     }

With this patch, HDR and BT.2020 enable at 3840x2160@60 under KWin 6.8, and the projector switches to HDR. Nothing else changed.

Related: #1285 / #1308 hit the same gate through a different path (HDMI3DSupported set by a parser bug on a monitor without 3D). #1308 does not help sinks that really support 3D; this change makes the gate harmless on Blackwell in both cases. Pre-Blackwell GPUs (e.g. RTX 4090, see the "No HDR on Projector" forum thread linked below) still need a different approach, for example allowing HDR while no 3D mode is active.

Forum reports of the same symptom: https://forums.developer.nvidia.com/t/bug-no-hdr-on-projector-works-on-windows-11-kde-plasma-6-8-wayland/386150 and https://forums.developer.nvidia.com/t/bug-unable-to-enable-projector-hdr-in-wayland/348156

Side effect worth knowing: after this rejection KWin falls back to a "low bandwidth" retry with implicit modifiers, which NVIDIA cannot render to, so the logs fill with GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT. That is what most reports quote, but it is only a consequence.

To Reproduce

1. Connect a sink whose EDID has HDMI VSDB 3D_present=1 and HDR static metadata (ST2084) over HDMI.
2. Try to enable HDR (KDE: kscreen-doctor output.HDMI-A-1.hdr.enable), or set Colorspace to BT2020_RGB in an atomic commit.
3. The driver check returns -EINVAL.

EDID (projector, HDMI-A-1)

00 ff ff ff ff ff ff 00 20 a3 30 00 01 00 00 00
1b 22 01 03 80 73 41 78 0a 00 41 ad 50 3d b3 27
0b 50 54 21 08 00 81 c0 81 40 81 80 01 01 01 01
01 01 01 01 01 01 08 e8 00 30 f2 70 5a 80 b0 58
8a 00 ba 88 21 00 00 1e 08 e8 80 18 71 38 2d 40
58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 48
49 53 45 4e 53 45 0a 20 20 20 20 20 00 00 00 fd
00 18 4b 0f 88 3c 00 0a 20 20 20 20 20 20 01 c7
02 03 7a 70 5d 61 20 22 5d 5e 5f 60 14 05 13 04
1f 10 15 16 01 02 11 21 12 03 65 66 62 63 64 07
06 3f 35 0f 07 07 15 07 50 57 06 00 3d 07 c0 5f
7e 01 5f 7e 07 67 04 00 83 01 00 00 e2 00 f9 e3
05 ff 01 78 03 0c 00 10 00 38 3c 20 c0 8a 01 02
03 04 01 41 00 7b 70 80 88 00 b6 c6 68 d8 5d c4
01 78 80 07 02 e5 01 8b 84 90 01 e3 06 0f 01 e4
0f 41 00 60 e5 01 62 41 da 01 00 00 00 00 00 e6

Bug Incidence

Always

More Info

Tested patched nvidia-modeset.ko built from the 615.78.08 source tarball (same srcversion as the distro module).