## Summary

On an Optimus laptop where the Intel iGPU drives the panel and the NVIDIA dGPU
drives no outputs, `default/hypr/nvidia.lua` sets `LIBVA_DRIVER_NAME=nvidia`
session-wide. Every VA-API client then decodes video on the dGPU while
rendering and compositing on the iGPU, so each decoded frame is copied across
PCIe before it can be drawn. The result is visible stutter on any page carrying
video, plus the dGPU held awake for no benefit.

## Expected

VA-API decode uses the GPU that renders and drives the display — `iHD` on this
machine.

## Actual

`LIBVA_DRIVER_NAME=nvidia` is exported to all clients. Chromium reports
`GL_RENDERER` as `ANGLE (Intel, Mesa Intel(R) UHD Graphics (CML GT2))` but loads
`nvidia_drv_video.so` for decode.

## Impact

Measured on this machine, scrolling a video-bearing page (an X timeline, which
autoplays video as posts enter the viewport):

| | with `nvidia` | with `iHD` |
|---|---|---|
| VA driver loaded by Chromium's GPU process | `nvidia_drv_video.so` | `iHD_drv_video.so` |
| Chromium memory resident on the dGPU | 201 MiB | 4 MiB, no compute apps |
| dGPU power draw | 14 W | 9.9 W |
| Scrolling | visibly juddery | smooth |

During a 120 s trace sampled at 250 ms, Chromium's renderer peaked at 484% of
one core and its GPU process at 228%, while Hyprland peaked at only 48% — the
compositor was never the bottleneck. Text-only pages were smooth throughout, and
Firefox was unaffected because it does not use VA-API here.

## Root cause

`default/hypr/nvidia.lua`:

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

`omarchy-hw-nvidia-gsp` matches on vendor `0x10de`, class `0x03*`, and device ID
`>= 0x1e00`. It does not distinguish a dGPU that drives displays from a
render-only dGPU on a hybrid laptop. This machine's TU106M (`10de:1f14`) matches,
so the branch fires even though the NVIDIA GPU drives nothing.

## Steps to reproduce

1. Optimus laptop, Intel iGPU driving the internal panel, NVIDIA dGPU (device ID
   `>= 0x1e00`) with no connected outputs.
2. `systemctl --user show-environment | grep LIBVA` → `LIBVA_DRIVER_NAME=nvidia`.
3. Open a page that autoplays video while scrolling; scroll it. Judder.
4. Close the browser and relaunch it as
   `LIBVA_DRIVER_NAME=iHD chromium --app=<url>`. Smooth.

Confirm which driver is loaded with:

```bash
GP=$(pgrep -f 'chromium.*type=gpu-process' | head -1)
grep -oE '[^/]*_drv_video\.so' /proc/$GP/maps | sort -u
```

## Suggested fix

Gate the VA-API line on whether the NVIDIA GPU actually drives a display, rather
than on its presence and device ID. The kernel already exposes this — on this
machine every NVIDIA connector is disconnected and the only connected output
belongs to i915:

```
card1-DP-1     [nvidia] = disconnected
card1-DP-2     [nvidia] = disconnected
card1-DP-3     [nvidia] = disconnected
card1-HDMI-A-1 [nvidia] = disconnected
card2-eDP-1    [i915]   = connected
```

so `/sys/class/drm/card*-*/status` gives a cheap sysfs-only test consistent with
the existing detectors' avoidance of `lspci`. `NVD_BACKEND` and
`__GLX_VENDOR_LIBRARY_NAME` may deserve the same treatment; I have not tested
those and am not claiming they are wrong.

### Caveat on that gate

On this chassis all four *external* outputs (HDMI-A-1, DP-1/2/3) belong to the
NVIDIA GPU; the iGPU owns only the internal eDP-1. So a naive "is any NVIDIA
connector connected" test would flip the moment an external monitor is plugged
in, changing decode behaviour under the user based on what is docked — plausibly
worse than being consistently wrong. Gating on whether the dGPU drives the
*primary* output, or simply preferring the driver that matches the GPU doing the
rendering, would be steadier. I do not have a docked machine to test against and
am not claiming to know the right rule, only that presence of the device is the
wrong signal.

## Workaround

`~/.config/hypr/envs.lua` containing `hl.env("LIBVA_DRIVER_NAME", "iHD")`,
required from `hyprland.lua` after `require("default.hypr.omarchy")`.

## Related

- #4901 (open, no maintainer response) — "Hybrid Intel+NVIDIA: Chromium hardware
  acceleration requires manual workarounds". Same hardware class, and the
  reporter found `LIBVA_DRIVER_NAME=iHD` to be a partial fix, but the issue is
  scoped to DMA-BUF visual corruption and black screens and works around it with
  `--disable-gpu-compositing`. It does not identify `default/hypr/nvidia.lua` as
  the source of the setting, and does not cover the video-decode stutter. This
  report is narrower: a detector that fires on the presence of a dGPU rather
  than on whether it drives a display.
- #6005 (closed) — `libva-nvidia-driver` on pre-Maxwell-2 NVIDIA. Different
  cause; also ends in VA-API pointed at hardware that should not serve it.

## Not established

Whether this is a regression. It was noticed immediately after an update to
4.0.1, but the previous package had already been pruned from the pacman cache,
so there was nothing to diff. mesa 26.1.7 → 26.2.1 landed in the same update and
may have changed the interop path; that is speculation, not a finding. The
misconfiguration itself is reproducible regardless.

## System details

- Omarchy 4.0.1-1, Hyprland 0.56.2, kernel 7.1.9-arch1-2
- Intel Core i7-10750H
- iGPU: Intel CometLake-H GT2 [UHD Graphics] `8086:9bc4`
- dGPU: NVIDIA TU106M [GeForce RTX 2070 Mobile / Max-Q Refresh] `10de:1f14`
- mesa 1:26.2.1-1, chromium 151.0.7922.173-1
- intel-media-driver 26.2.4-1, libva-nvidia-driver 0.0.17-1