Hybrid laptops: LIBVA_DRIVER_NAME=nvidia breaks all hardware video decoding when the compositor renders on the iGPU

[Johary-hub]

What happens

On a hybrid laptop (AMD iGPU + NVIDIA dGPU) where Hyprland renders on the AMD iGPU, every browser video plays with audio but a permanently black picture. Any VA-API client hangs forever instead of decoding.

default/hypr/nvidia.lua sets LIBVA_DRIVER_NAME=nvidia as soon as an NVIDIA GPU with GSP is present:

if o.shell_succeeds(o.shell_quote(nvidia)) then
  if o.shell_succeeds(o.shell_quote(nvidia_gsp)) then
    hl.env("NVD_BACKEND", "direct")
    hl.env("LIBVA_DRIVER_NAME", "nvidia")

But presence is not the same as being the rendering GPU. On this machine aquamarine picks the AMD card as primary:

drm: Starting backend for /dev/dri/card2, with driver amdgpu
drm: gpu /dev/dri/card2 becomes primary drm
drm: Starting backend for /dev/dri/card1, with driver nvidia-drm with primary /dev/dri/card2
CDRMRenderer(drm): Using device /dev/dri/card2

Forcing every VA-API client onto nvidia_drv_video.so then wedges decoding. The decoder never returns a frame; audio keeps playing on the CPU, so the symptom reads as "video is black, sound is fine" — which sends users hunting for a codec or browser problem.

Expected

Hardware video decoding should use the GPU that actually renders the session, or be left to libva's per-device autodetection.

Reproduce

Hybrid laptop, Hyprland rendering on the iGPU, libva-nvidia-driver installed. Play any hardware-decoded video in Chromium/Brave: audio plays, picture stays black.

Reduced to one command, no browser involved:

ffmpeg -f lavfi -i testsrc2=size=640x360:rate=25:duration=3 -c:v libx264 -pix_fmt yuv420p t.mp4

# hangs forever (Omarchy's default environment)
LIBVA_DRIVER_NAME=nvidia   ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD129 -i t.mp4 -f null -

# decodes fine
LIBVA_DRIVER_NAME=radeonsi ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD129 -i t.mp4 -f null -

# also fine (libva autodetection)
env -u LIBVA_DRIVER_NAME  ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD129 -i t.mp4 -f null -

renderD129 is the AMD node here. VA-API initialisation succeeds on both nodes; only decoding hangs. H.264, HEVC and VP9 all decode correctly once the driver is radeonsi. No kernel errors, no GPU reset, nothing in the journal — the ring simply never completes, which makes this hard to diagnose from logs.

Workaround

Override in the user config, which loads after the defaults:

hl.env("LIBVA_DRIVER_NAME", "radeonsi")

Suggested fix

Gate the LIBVA_DRIVER_NAME=nvidia line on the NVIDIA card actually being the rendering GPU rather than merely present. NVD_BACKEND and __GLX_VENDOR_LIBRARY_NAME are separate concerns and can stay as they are.

Second, related symptom

On the same machine the external monitor is wired to the NVIDIA card while the desktop renders on AMD, so the hardware cursor has to be blitted across GPUs and fails continuously — 10362 occurrences in a single session:

ERR: EGL (blit): glCheckFramebufferStatus failed: 1282
ERR: drm: Backend requires blit, but cursor blit failed

cursor { no_hardware_cursors = true } silences it. Worth considering as a default when aquamarine reports more than one GPU with outputs on a non-primary card.

System

• Omarchy 4.0.2-1
• Hyprland 0.56.2-1, aquamarine, Wayland
• CPU: AMD Ryzen 7 8845HS (Radeon 780M / VCN 4.0)
• GPUs: NVIDIA AD106M (RTX 4070 Max-Q, nvidia-open-dkms 610.57.04-1) + AMD HawkPoint1 (amdgpu)
• Displays: internal eDP-1 on the AMD card, external HDMI-A-1 on the NVIDIA card
• mesa 1:26.2.1-1, libva 2.24.1-1, libva-nvidia-driver 0.0.17-1, linux 7.1.9.arch1-2

[remydw]

Duplicate of #8726. That thread now has an independent confirmation on different silicon (Radeon 890M + RTX 5080 Max-Q), an A/B of the session environments, and a review of the two pending fixes (#9483, #10589) — including a case where a boot_vga-based detector keeps the bug on hardware whose non-NVIDIA display device exposes no boot_vga attribute.

[bjarneo]

Automated duplication check: this issue looks similar to #8215, which covers the same forced NVIDIA VA-API breaks hybrid laptop video. I keep that one open and close this one to keep the discussion in one place.

If you feel this is the wrong decision, please open the issue again with a note on the difference.