## What happens

On a hybrid laptop whose internal panel is driven by the **AMD iGPU**, video in
Chromium plays audio with a completely black picture. The page itself renders
perfectly — thumbnails, avatars, comments — only the video frame stays black and
the player never leaves 0:00.

## Cause

`default/hypr/nvidia.lua` sets the VA-API driver purely on "is an NVIDIA GPU
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")
    hl.env("__GLX_VENDOR_LIBRARY_NAME", "nvidia")
```

It does not check **which GPU is actually driving the display**. On this machine
the eDP panel hangs off the AMD Cezanne iGPU (`card2` → `amdgpu`), so forcing
`LIBVA_DRIVER_NAME=nvidia` points hardware video decode at a GPU that isn't
scanning out, through the `libva-nvidia-driver` shim, which fails here.

Audio is decoded on a separate CPU path, which is why sound is unaffected and
the symptom looks like a rendering bug rather than a decode one.

This should affect any NVIDIA Optimus / hybrid laptop where the internal panel
is wired to the integrated GPU — a large share of gaming laptops.

## Reproduce

On a hybrid laptop with the panel on the iGPU, open any YouTube video in
Chromium. Audio plays, picture is black.

## Evidence

VA-API initialises on the AMD render node and fails on the NVIDIA one:

```
$ LIBVA_DRIVER_NAME=radeonsi ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129 ...
(succeeds)

$ LIBVA_DRIVER_NAME=nvidia ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128 ...
[h264_vaapi] No usable encoding entrypoint found for profile VAProfileH264...
```

Which GPU drives the panel:

```
$ basename $(readlink -f /sys/class/drm/card2/device/driver)
amdgpu
$ cat /sys/class/drm/card2-eDP-1/status
connected
```

A/B test, same video file, same machine, isolated Chromium profiles:

- `LIBVA_DRIVER_NAME=nvidia` → blank window, no picture
- `LIBVA_DRIVER_NAME=radeonsi` → renders correctly

## Workaround

Override in user config, loaded after the Omarchy defaults:

```lua
-- ~/.config/hypr/hyprland.lua
hl.env("LIBVA_DRIVER_NAME", "radeonsi")
```

## Suggested fix

Gate the `LIBVA_DRIVER_NAME` line on the NVIDIA GPU actually driving a connected
output, rather than merely being present. The existing detectors already read
cached sysfs IDs; the connector's driver can be read the same way by walking
`/sys/class/drm/card*-*/status` and resolving each card's driver. Where the
panel is on the iGPU, either leave `LIBVA_DRIVER_NAME` unset or set it to the
iGPU's driver.

Note that `__GLX_VENDOR_LIBRARY_NAME` and `NVD_BACKEND` are a separate question
— GL rendering on the dGPU is reasonable on these machines. It is specifically
the VA-API decode path that needs to follow the display.

## System

| | |
|---|---|
| Omarchy | 4.0.3-1 |
| Kernel | 7.2.3-arch1-3 |
| Machine | ASUS ROG Zephyrus G14 GA401QC |
| CPU | AMD Ryzen 7 5800HS with Radeon Graphics |
| GPUs | NVIDIA RTX 3050 Mobile (dGPU) + AMD Cezanne (iGPU, drives panel) |
| Hyprland | 0.56.2 |
| NVIDIA driver | 610.57.04 |
| mesa | 1:26.2.2-1 |
| libva-nvidia-driver | 0.0.18-1 |