### System details

CPU: Intel Core i7-10850H, GPUs: Intel CometLake-H GT2, NVIDIA Quadro T1000 Mobile, OS: Omarchy 4.0.4-1

### What's wrong?

# Hybrid Intel+NVIDIA laptops: `nvidia.lua` forces `LIBVA_DRIVER_NAME=nvidia` even when Hyprland composites on the iGPU, breaking video in Chromium/Electron apps

## Summary

`default/hypr/nvidia.lua` decides to apply the NVIDIA environment based on whether an
NVIDIA GPU is **present**, not on whether it is the GPU the compositor actually renders
on. On a hybrid (Optimus-style) laptop where Hyprland drives the displays via the Intel
iGPU, this points VA-API at the wrong GPU and breaks hardware video decode for every
Chromium- and Electron-based app.

Observed as two symptoms that initially looked unrelated:

- **Brave**: video-heavy pages (x.com in particular) flicker, and content intermittently
  disappears. Markedly worse when the window is small.
- **Signal Desktop**: videos do not play at all.

## Expected vs actual

**Expected:** hardware video decode uses the GPU that composites the session, so video
plays and pages render correctly out of the box.

**Actual:** VA-API is forced to the NVIDIA driver while the Chromium/Electron GPU process
is pinned to the Intel render node. Decoded frames are produced on a GPU the consumer
cannot import from.

## Root cause

`default/hypr/nvidia.lua` gates purely on presence detection:

```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")
  ...
```

On this machine:

1. **Hyprland composites on the Intel GPU.** `card2` (`0000:00:02.0`, Intel) is held open
   by Hyprland and Xwayland. `card1` (`0000:01:00.0`, NVIDIA) is held open by nothing.
   Both `eDP-1` and `DP-1` come off Intel KMS.

2. **Chromium/Electron correctly follow the compositor** and pin their GPU process to the
   Intel render node. From the live `--type=gpu-process` command lines of both Brave and
   Signal:

   ```
   --render-node-override=/dev/dri/renderD129     # renderD129 = Intel (00:02.0)
   ```

3. **But `LIBVA_DRIVER_NAME=nvidia` + `NVD_BACKEND=direct` sends decode to the other GPU.**
   In `direct` mode the NVIDIA VA-API driver ignores the DRM fd it is handed and talks to
   the NVIDIA GPU directly. The resulting frames live in NVIDIA memory, and a GPU process
   pinned to `renderD129` cannot import them.

### Why this is easy to misdiagnose

`vainfo` gives a false all-clear. Because the NVIDIA driver in `direct` mode never uses the
fd, it reports healthy **even when explicitly pointed at the Intel node** — which is
exactly the broken configuration:

```
$ LIBVA_DRIVER_NAME=nvidia vainfo --display drm --device /dev/dri/renderD129
vainfo: Driver version: VA-API NVDEC driver [direct backend]
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      ...
```

Both drivers also enumerate correctly against their own nodes, so nothing in the VA-API
layer looks wrong until you test an actual app.

## Steps to reproduce

On a hybrid Intel+NVIDIA laptop where Hyprland renders on the Intel GPU:

1. Confirm the compositor is on the iGPU — `card1` (NVIDIA) is not held open by any process:
   ```bash
   for n in /dev/dri/card1 /dev/dri/card2; do echo "$n:"; \
     for p in /proc/[0-9]*; do ls -l $p/fd 2>/dev/null | grep -q "$n$" && \
       echo "  $(cat $p/comm)"; done; done
   ```
2. Confirm the inherited environment: `echo $LIBVA_DRIVER_NAME` → `nvidia`
3. Open <https://x.com> in Brave and shrink the window → flickering and disappearing content.
4. Open a video in Signal Desktop → it does not play.
5. Override the driver and both are fixed:
   ```bash
   LIBVA_DRIVER_NAME=iHD brave-origin --user-data-dir=/tmp/bt-ihd https://x.com   # no flicker
   LIBVA_DRIVER_NAME=iHD signal-desktop                                          # video plays
   ```

Step 5 is also the reverse reproduction: relaunching either app with
`LIBVA_DRIVER_NAME=nvidia` brings the fault straight back.

## Suggested fix

Apply the NVIDIA VA-API environment only when the NVIDIA GPU is the one the compositor
renders on, rather than when it is merely present.

The simplest robust option is to **not set `LIBVA_DRIVER_NAME` at all on hybrid systems**.
libva already selects the right driver from the DRM fd it is given, so each app gets the
correct driver for whichever render node it opens. Forcing the variable globally is what
defeats that.

If an explicit value is preferred, gate it on the render node Hyprland actually opened
(e.g. resolve the primary DRM device and set `iHD`/`radeonsi`/`nvidia` to match) rather
than on presence detection.

`__GLX_VENDOR_LIBRARY_NAME=nvidia` is likely wrong in the same circumstances, for the same
reason — it forces the NVIDIA GLX vendor for X11/Xwayland clients while Xwayland is running
on the Intel GPU. I have not confirmed a user-visible failure from it, so it may warrant a
separate look.

## User-side workaround

Add to `~/.config/hypr/hyprland.lua`, which loads after the Omarchy defaults:

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

Then log out and back in. A reload is not sufficient: the systemd user environment is
imported at session start, and long-lived launchers (quickshell) keep the old value and
pass it to everything they spawn.

## System details

| | |
|---|---|
| Omarchy | 4.0.4-1 |
| Kernel | 7.2.5-3-omarchy |
| Hyprland | 0.56.2 (`efb5099`) |
| CPU | Intel Core i7-10850H |
| iGPU | Intel CometLake-H GT2 [UHD Graphics] `8086:9bc4` — `00:02.0`, `card2`, `renderD129` |
| dGPU | NVIDIA Quadro T1000 Mobile `10de:1fb9` — `01:00.0`, `card1`, `renderD128` |
| mesa | 1:26.2.2-1 |
| nvidia-open-dkms | 610.57.04-1 |
| intel-media-driver | 26.2.4-1 |
| libva / libva-nvidia-driver | 2.24.1-1 / 0.0.18-1 |
| Brave Origin | 153.1.95.102 |
| signal-desktop | 8.26.0-1 |

Session environment as shipped by `nvidia.lua`:

```
LIBVA_DRIVER_NAME=nvidia
NVD_BACKEND=direct
__GLX_VENDOR_LIBRARY_NAME=nvidia
```

No `i915` GPU hangs or resets appear in the journal, and no core dumps are produced — this
is not a driver crash.

> Note (seperate issue): `omarchy debug` is referenced in the contributing docs but does not exist in
> 4.0.4-1 (`Unknown Omarchy command`), so the details above were gathered by hand.