### System details

Intel i7-13800H, Intel Iris Xe (`0000:00:02.0`) + NVIDIA RTX 2000 Ada Laptop (`0000:01:00.0`), Dell Precision 5480, Omarchy 4.0.2-1, kernel 7.1.9-arch1-2, nvidia-open-dkms 610.57.04-1, intel-media-driver 26.2.4-1, mesa 1:26.2.1-1, libva-nvidia-driver 0.0.17-1

### What's wrong?

On a hybrid laptop where the **Intel iGPU drives the display** and the NVIDIA dGPU is compute-only, `default/hypr/nvidia.lua` points OpenGL and VA-API at the dGPU:

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

The detectors only ask *"is there an NVIDIA GPU with GSP?"* — never *"does it drive a display?"* On this machine it does not. The result is that apps composite on Intel while decoding video on NVIDIA, and that cross-GPU path corrupts the whole window, not just the video surface.

Symptom: playing a video (Reddit, among others) in Chrome glitches the entire browser window — stutter, flicker, black video, playback that won't start.

### Evidence

The Intel render node is `renderD129` (`0000:00:02.0`), NVIDIA is `renderD128` (`0000:01:00.0`). Calling `vaInitialize()` on the **Intel** node:

| `LIBVA_DRIVER_NAME` | Driver actually loaded |
| --- | --- |
| `nvidia` (Omarchy's default here) | `VA-API NVDEC driver [direct backend]` |
| `iHD` | `Intel iHD driver for Intel(R) Gen Graphics - 26.2.4` |

So VA-API is handed the NVIDIA decoder for a surface that lives on Intel.

This machine's topology, which the detectors don't consider:

```
0000:00:02.0 (i915)   boot_vga=1    card2-eDP-1 = connected
0000:01:00.0 (nvidia) boot_vga=n/a  no DRM connectors at all
```

The dGPU has **zero** connectors — it cannot drive a display in this configuration.

### Secondary issue: the value depends on how the app was launched

`hl.env` sets these for Hyprland's children, but apps started in a uwsm systemd scope read `environment.d` instead. Chrome (`app-Hyprland-google-chrome-stable-*.scope`) inherited **no** libva vars at all, while a terminal-launched Chrome inherits `nvidia`. Same browser, different video decoder depending on launch path, which made this intermittent and hard to pin down.

### Steps to reproduce

1. Hybrid laptop, Intel iGPU driving the panel, NVIDIA dGPU with GSP, `nvidia-open-dkms`
2. Log into Hyprland under Omarchy
3. `echo $LIBVA_DRIVER_NAME` -> `nvidia`
4. Play a video in Chrome — the whole window glitches

### Suggested fix

Gate the graphics env on whether the dGPU actually drives a display, rather than on its mere presence. Either check is cheap and reads only cached sysfs, so it keeps the existing constraint of not resuming a runtime-suspended GPU:

- the dGPU has no `/sys/class/drm/card<N>-*` connectors, or none `connected`
- the iGPU is `boot_vga=1`

When the dGPU is compute-only, leaving `LIBVA_DRIVER_NAME` / `__GLX_VENDOR_LIBRARY_NAME` unset (or set to `iHD` / `mesa`) keeps rendering and decode on the display GPU. CUDA is unaffected either way — it reads neither variable — so compute workloads keep full use of the dGPU.

### Workaround

Override after Omarchy's defaults load, in **both** places so uwsm-launched apps agree:

```bash
# ~/.config/hypr/hyprland.lua
hl.env("LIBVA_DRIVER_NAME", "iHD")
hl.env("__GLX_VENDOR_LIBRARY_NAME", "mesa")

# ~/.config/environment.d/55-gpu.conf
LIBVA_DRIVER_NAME=iHD
__GLX_VENDOR_LIBRARY_NAME=mesa
```

Confirmed fixed after a logout/login.

### Notes

`omarchy debug --no-sudo --print` is referenced in the docs but isn't a command in 4.0.2-1 (`Unknown Omarchy command`), so system details are inline above rather than attached.