## What happens

On a hybrid AMD + NVIDIA laptop where the internal panel is driven by the AMD iGPU,
Omarchy sets `LIBVA_DRIVER_NAME=nvidia`, which breaks **all hardware-decoded video**.
Video players render as a black rectangle. The media itself loads and decodes fine —
in Chromium the `<video>` element reports `readyState=4`, `error=null`, correct
`videoWidth/videoHeight` — the frames simply never reach the screen.

This affects any page with a `<video>` element (GitHub video attachments, YouTube, etc.)
and is present from install, on every boot.

## Expected

Hardware-decoded video renders.

## Root cause

`/usr/share/omarchy/default/hypr/nvidia.lua` sets, whenever a GSP-capable NVIDIA GPU
is detected:

```lua
hl.env("NVD_BACKEND", "direct")
hl.env("LIBVA_DRIVER_NAME", "nvidia")
hl.env("__GLX_VENDOR_LIBRARY_NAME", "nvidia")
```

The detector checks only *whether* an NVIDIA GPU exists — not whether it is the GPU the
compositor renders on. On this machine the connectors are split across both GPUs:

```
card2-eDP-1     (internal panel)  -> 0000:06:00.0  AMD HawkPoint2 iGPU
card1-HDMI-A-1  (external)        -> 0000:01:00.0  NVIDIA RTX 4050 Mobile
```

Hyprland composites on the AMD iGPU. Forcing `LIBVA_DRIVER_NAME=nvidia` routes VA-API
decode to NVDEC on the dGPU, and NVDEC output carries an NVIDIA-vendor DRM modifier that
`radeonsi` cannot import. The zero-copy path from decoder to compositor is therefore
structurally impossible, and decoded frames are dropped instead of displayed.

The same cross-GPU import failure shows up in Hyprland's logs as repeated failed
hardware-cursor blits (`GL_INVALID_OPERATION`), which force a software cursor.

## Steps to reproduce

1. Hybrid AMD + NVIDIA laptop, internal panel wired to the AMD iGPU.
2. Install Omarchy; confirm `LIBVA_DRIVER_NAME=nvidia` is exported into the session.
3. Open any page with an HTML5 `<video>` element in Chromium.
4. The player is a black rectangle; controls work, timeline does not paint.

## Verification (A/B)

Same page, same Chromium binary, ~60s apart, launched via Playwright with only the
environment differing. Screen captured with `grim` (a CDP screenshot does **not**
reproduce this — it bypasses the compositing path):

| Environment | Result |
|---|---|
| `LIBVA_DRIVER_NAME=nvidia` (Omarchy default) | **black box** |
| `LIBVA_DRIVER_NAME=radeonsi` | renders correctly |
| `LIBVA_DRIVER_NAME` **unset** (libva auto-detects) | renders correctly |

Isolated further: changing `LIBVA_DRIVER_NAME` **alone** is sufficient. No EGL/GLX change is
needed, so the NVIDIA-driven external output keeps working.

Unsetting the variable entirely is stable: GPU-process count held constant across page load,
no renderer crash, no browser disconnect, `readyState=4` with correct dimensions.

## Suggested fix

Gate the `LIBVA_DRIVER_NAME=nvidia` assignment on the NVIDIA GPU actually being the
render device the compositor uses, rather than merely being present.

On hybrid systems where the compositor renders on the iGPU, either option works (both
verified above):

- leave `LIBVA_DRIVER_NAME` unset and let libva auto-detect per render node, or
- set it to match the render GPU (`radeonsi` for AMD, `iHD` for Intel).

Leaving it unset is the smaller change and avoids hardcoding a per-vendor driver name.
`NVD_BACKEND=direct` becomes inert once the NVIDIA VA-API driver is no longer selected.

## Workaround

In `~/.config/hypr/hyprland.lua`, after `require("default.hypr.omarchy")`:

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

Requires a re-login; `hyprctl reload` does not re-export session env.

## System details

- Omarchy 4.0.1-1 (stable channel)
- CPU: AMD Ryzen 7 7445HS w/ Radeon 740M Graphics
- GPUs: NVIDIA AD107M RTX 4050 Max-Q/Mobile [10de:28a1] + AMD HawkPoint2 [1002:1901]
- Kernel 7.1.9-arch1-2
- nvidia-open-dkms 610.57.04-1, nvidia-utils 610.57.04-1, libva-nvidia-driver 0.0.17-1
- mesa 1:26.2.1-1
- Hyprland 0.56.2
- Chromium 151.0.7922.173 (Arch)