## 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*:

```lua
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:

```bash
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:

```lua
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