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

Open
  • Is something wrong?
#1,475 3 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c, linux
Domain
operating-systems

Research direction

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.

Written by the indexing model from the issue text.

Description

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).

Dominant language
C
Stars
17.5k
Forks
1.9k
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NVIDIA/open-gpu-kernel-modules

All issues in NVIDIA/open-gpu-kernel-modules

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.