[610.43.02] Invalid HDR metadata (min_lum ≥ max_lum) passed through to Wayland compositor unfiltered, causing client termination; system-wide HDR also

Graphics / Linux Linux
1

I’ve been troubleshooting this issue with AI and Google, and also have been in contact with KWin developer, for a few days now. Here is the issue:

Driver: 610.43.02
GPU: NVIDIA GeForce RTX 4070
OS: CachyOS Linux (Arch-based)
Kernel: 7.0.12-1-cachyos (also reproduced on 6.18.35 LTS)
Desktop/Compositor: KDE Plasma 6.7.1, KWin, Wayland
Display: ASUS ROG Strix XG27AQDPG QD-OLED, HDR10, DisplayPort, 2560x1440@500Hz

Summary:

Two related HDR problems on driver 610.43.02 with a Wayland compositor (KWin). Both persist on Plasma 6.7.1, and Issue 2 is visible on the bare desktop with no application running, which points at the driver/HDR-output pipeline rather than any individual application.

Issue 1 — Invalid HDR metadata passed through unfiltered, crashing Wayland clients:

When an application submits HDR10 mastering-display metadata where minimum luminance ≥ maximum luminance, the NVIDIA driver passes this invalid metadata through to the Wayland compositor unchanged. Mesa’s WSI implementation filters out such invalid metadata before it reaches the compositor (reference: wsi_common_wayland.c), so AMD users are unaffected. On NVIDIA, the compositor receives the out-of-spec values and, per the Wayland color-management protocol, terminates the client connection.

Error observed (via Proton/Wine Wayland driver log):

[destroyed object]: error 5: min_lum can't be higher or equal to max_lum
err:waylanddrv:wayland_read_events_thread Failed to read events from the compositor, terminating process

The KWin maintainer has confirmed this is ultimately a driver-side issue — the driver should sanitize or clamp invalid luminance metadata rather than forwarding it. Reference: KDE bug 521952.

Reproduction (Issue 1):

  1. NVIDIA GPU, driver 610.43.02, Wayland compositor (KWin 6.7.1), HDR-capable display with HDR enabled.
  2. Launch an HDR title whose engine emits invalid HDR10 metadata (min ≥ max). Sekiro: Shadows Die Twice (via Proton, PROTON_ENABLE_WAYLAND=1 DXVK_HDR=1 ENABLE_HDR_WSI=1) is a reliable repro.
  3. Application crashes immediately on swapchain creation with the error above.

Issue 2 — System-wide HDR output severely crushed (desktop included):

With HDR enabled in the compositor, the entire output — including the bare desktop, with no application running — shows severely crushed blacks and incorrect tone mapping. Disabling HDR returns the desktop to correct colors. This occurs independent of any game or Proton layer, indicating the HDR output pipeline itself is affected. This coincides with the new DRM color pipeline support introduced in the 610 series; setting color_pipeline=0 on the nvidia-drm module did not resolve it.

Reproduction (Issue 2):

  1. NVIDIA GPU, driver 610.43.02, Wayland compositor, HDR-capable display.
  2. Enable HDR in the compositor’s display settings.
  3. Observe the desktop (no application needed): blacks are crushed and tone mapping is visibly wrong. Disabling HDR restores correct output.
2

Additional reproduction with a concrete protocol trace, confirming the exact
invalid values being sent.

Environment

  • GPU: GeForce RTX 4090
  • Driver: 610.43.03 (open kernel module)
  • Kernel: 7.1.3 (CachyOS)
  • Compositor: KWin 6.7.3 / Plasma 6.7.3, Wayland
  • Compositor advertises wp_color_manager_v1 v2 (and frog_color_management_factory_v1 v1)
  • Game: D3D12 title via Proton (vkd3d-proton), env:
    PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1 DXVK_HDR=1

The game reliably crashes ~20s after launch. WAYLAND_DEBUG=1 shows the client
building an HDR image description and the compositor terminating it:

-> wp_image_description_creator_params_v1.set_primaries_named(6) # BT.2020
→ wp_image_description_creator_params_v1.set_tf_named(11) # ST2084 (PQ)
→ wp_image_description_creator_params_v1.set_max_cll(0)
→ wp_image_description_creator_params_v1.set_max_fall(0)
→ wp_image_description_creator_params_v1.set_mastering_display_primaries(0,0,0,0,0,0,0,0)
→ wp_image_description_creator_params_v1.set_mastering_luminance(0, 0)
→ wp_image_description_creator_params_v1.create(…)
{Display Queue} wl_display#1.error(nil, 5, “min_lum can’t be higher or equal to max_lum”)

Root cause
The game enables PQ/BT.2020 but provides no mastering-display metadata. The
NVIDIA Vulkan WSI still emits the optional set_mastering_luminance request with
min_lum = 0, max_lum = 0 (and an all-zero mastering block: max_cll=0, max_fall=0,
primaries all 0). The wp_color_manager_v1 protocol requires min_lum < max_lum, so
KWin correctly rejects it with a protocol error and destroys the client. KWin is
behaving per spec.

The WSI should either omit the optional set_mastering_luminance()/mastering-display
requests when no valid metadata is available, or clamp/sanitize before sending —
which is exactly what Mesa’s WSI does, and why AMD is unaffected.

This is not KWin-specific: wlroots reports the equivalent “max luminance must be
greater than min luminance”.

Workarounds that work today

  • Run the game nested in gamescope with --hdr-enabled (it presents through a
    different path and produces valid metadata). HDR is preserved.
  • Or disable the HDR WSI entirely. Note: the env vars must be ABSENT, not set to
    0 — Proton/DXVK check for presence, so PROTON_ENABLE_HDR=0 / DXVK_HDR=0 still
    enable it. Unset them.