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

Ouverte
#1,475 3 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
55/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
c, linux

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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

Langage dominant
C
Étoiles
17.6k
Forks
2k
Métriques de merge des PR
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de NVIDIA/open-gpu-kernel-modules

Toutes les issues de NVIDIA/open-gpu-kernel-modules

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.