### System details

Lenovo Legion 5 15IAX10 · Intel Core Ultra 7 255HX (Arrow Lake) · Intel Arrow Lake-S iGPU `[8086:7d67]` (i915) + NVIDIA GeForce RTX 5070 Max-Q `[10de:2d18]` (nvidia 610.57.04) · Omarchy 4.0.2-1 (stable) · Hyprland 0.56.2 · kernel 7.1.9-arch1-2 · mesa 26.2.1 · libva 2.24.1 · libva-nvidia-driver 0.0.17 · chromium 151.0.7922.173

### What's wrong?

On a hybrid laptop whose compositor renders on the **Intel** iGPU, `default/hypr/nvidia.lua` still exports `LIBVA_DRIVER_NAME=nvidia` session-wide. That forces every VA-API client onto the NVIDIA VA driver even though the active render node belongs to i915. The practical result is persistently corrupted hardware-decoded video, and — once so far — a hard abort of Chromium's GPU process.

**Symptoms, in order of how often they occur.** The everyday symptom is visual artifacts and glitching, and it appears *only* when watching a live stream with the chat panel open — ordinary video playback on the same machine looks fine. That corruption is routine. The GPU process actually aborting is rare: it has happened **once**, and the core dump analysed below is that one occurrence. Please read the crash as an occasional escalation of the everyday corruption, not as the reliable outcome.

**Where it comes from** — `default/hypr/nvidia.lua:10-19`, loaded from `default/hypr/envs.lua:39`:

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

Both detectors return true here (`omarchy-hw-nvidia` → 0, `omarchy-hw-nvidia-gsp` → 0), so this branch is taken. Neither detector asks whether the NVIDIA GPU is the one actually **rendering** — only whether it exists and uses GSP.

**Why that is wrong on this machine** — `omarchy-debug` reports:

```
Device-1 Intel Arrow Lake-S   driver i915    ports active eDP-2   bus-ID 00:02.0
Device-2 NVIDIA GB206M        driver nvidia  ports active none    bus-ID 02:00.0
Display wayland  compositor Hyprland v 0.56.2  driver gpu i915
```

The dGPU drives no displays; the compositor renders on i915. Chromium correctly follows it onto the Intel render node — the browser passes `--render-node-override=/dev/dri/renderD129`, and `/dev/dri/by-path/pci-0000:00:02.0-render` → `renderD129` → i915. But `LIBVA_DRIVER_NAME=nvidia` overrides libva's DRM-based driver autodetection, so libva loads `nvidia_drv_video.so` against an Intel render node anyway.

**The crash.** Chromium's GPU process aborted with `SIGTRAP` (`si_code: SI_KERNEL`). Disassembling the core shows RIP on `ud2` directly after an `int3` — Chromium's `IMMEDIATE_CRASH()`, i.e. a deliberate `CHECK`/`LOG(FATAL)`, not a segfault or OOM (23 GiB free, no OOM kills, no Xid or DRM errors in the kernel log).

Crashpad annotations from the same crash:

```
last-video-decoder: VaapiVideoDecoder:codec=vp9:profile=12:size=640x360:cs=[1,1,2,1]:hdrm=0
gpu-gl-renderer:    ANGLE (Intel, Mesa Intel(R) Graphics (ARL), OpenGL ES 3.2 Mesa 26.2.1-arch1.1)
```

So GL was on Intel/Mesa while VA-API decode ran on NVIDIA. `libcuda.so.1`, `libnvcuvid.so.1` and `nvidia_drv_video.so` were all mapped into the process, and the last threads it ever created were exactly those CUDA/NVDEC threads (TIDs 117252-117256) — with the systemd-coredump service taking PID 117257, the very next PID. The process died within milliseconds of NVDEC initialising.

The live-stream trigger fits that timing: 640x360 is a low adaptive-bitrate rung, and live streams renegotiate quality far more often than static videos do. Every renegotiation re-initialises the decoder, so a long stream hits the cross-GPU import path over and over. That shape matches the observed symptom split — most of those hits degrade into visible corruption, while one happened to land on a fatal `CHECK`, immediately after a fresh NVDEC init. This reading is inference; I have not instrumented the quality switches.

### Steps to reproduce

1. Hybrid laptop, NVIDIA dGPU present with GSP, Hyprland rendering on the Intel iGPU (dGPU driving no displays).
2. Confirm the env Omarchy sets: `LIBVA_DRIVER_NAME=nvidia`, `NVD_BACKEND=direct`.
3. In Chromium with hardware decode enabled, watch a **live stream with the chat panel open** (VP9, adaptive bitrate). Plain video playback is not sufficient to trigger it.
4. Visual artifacts and glitching appear during playback. This part reproduces consistently.
5. Rarely, the GPU process aborts outright (`SIGTRAP`) and `coredumpctl` records a `chromium` core with `--type=gpu-process`. Observed once; I have no reliable way to force it.

### Expected

VA-API should target the GPU that is actually rendering. On a hybrid laptop where the compositor is on the iGPU, `LIBVA_DRIVER_NAME` should not be pinned to `nvidia`.

### Suggested fix

Gate the `LIBVA_DRIVER_NAME` / `NVD_BACKEND` exports on the NVIDIA GPU actually being the **rendering** device, rather than merely present. That distinction is visible in sysfs:

```
card0-eDP-2      status=connected     enabled=enabled     # 0000:00:02.0, i915
card0-DP-2       status=disconnected  enabled=disabled
card0-DP-3       status=disconnected  enabled=disabled
card1-DP-1       status=disconnected  enabled=disabled    # 0000:02:00.0, nvidia
card1-eDP-1      status=disconnected  enabled=disabled
card1-HDMI-A-1   status=disconnected  enabled=disabled
```

Every connector on the dGPU is disconnected and disabled; the iGPU drives the panel. A detector along the lines of "this NVIDIA card has no enabled connector, so it is not the rendering device" would skip the branch on machines like this one.

One caveat, given the comment already in `nvidia.lua` about `lspci` waking a runtime-suspended GPU and blowing the 1.5s reload budget: I would use the `enabled` attribute rather than `status`, since `status` can trigger a connector probe. I could not measure that hazard here — both reads took ~3ms, but this laptop's dGPU was in `runtime_status: active` at the time, so the test says nothing about the suspended case. Worth checking on a machine where the dGPU is asleep.

`__GLX_VENDOR_LIBRARY_NAME=nvidia` may deserve the same treatment; I have not tested its effects here.

Worth noting for anyone hitting this: installing `intel-media-driver` alone does **not** fix it, because `LIBVA_DRIVER_NAME=nvidia` overrides libva's autodetection and the Intel driver is never loaded.

### Limits of this report

Arch's debuginfod returns 404 for chromium's build-id (`9bee9698c742a867e47bda362a8e54c394022d49`) and the binary exports no symbols in the relevant range, so I could not symbolize the crashing frames. That the failing `CHECK` is specifically in the cross-GPU frame-import path is an inference from the annotations, the loaded modules and the thread-creation timing — the abort itself, the env vars, the render-node mapping and the driver mismatch are all directly verified.

---

Filed by Claude Opus 5 via Claude Code.