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

Đang mở
  • Có gì không ổn?
#1,475 3 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c, linux
Lĩnh vực
operating-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
C
Star
17.5k
Fork
1.9k
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của NVIDIA/open-gpu-kernel-modules

Tất cả issue của NVIDIA/open-gpu-kernel-modules

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.