## Summary

On a hybrid Intel + NVIDIA laptop where Hyprland renders on the **Intel** iGPU, `default/hypr/nvidia.lua` still forces `LIBVA_DRIVER_NAME=nvidia`. Chromium then decodes video on NVDEC but composites on Intel, cannot import the decoded surfaces, and drops **every** frame — video is blank while audio plays normally.

The detector only asks "is an NVIDIA GPU present?", not "is NVIDIA the compositor's render device?"

## The code

`default/hypr/nvidia.lua` (current `main`):

```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")   -- <-- unconditional
    hl.env("__GLX_VENDOR_LIBRARY_NAME", "nvidia")
```

`bin/omarchy-hw-nvidia` exits 0 if *any* PCI device has vendor `0x10de` and class `0x03*`. On an Optimus laptop that is always true, even when the dGPU renders nothing.

## What actually happens

Hyprland has the Intel iGPU as its render device:

```
$ ls -l /proc/$(pgrep -x Hyprland)/fd | grep renderD129   # 0000:00:02.0, Intel UHD 770
```

Chromium follows the compositor onto the same node:

```
$ ps -o args -C chromium | grep gpu-process
/usr/lib/chromium/chromium --type=gpu-process --ozone-platform=wayland \
  --render-node-override=/dev/dri/renderD129 ...
```

But `LIBVA_DRIVER_NAME=nvidia` makes libva load the NVDEC backend regardless of which node was opened:

```
libva: User environment variable requested driver 'nvidia'
libva: Trying to open /usr/lib/dri/nvidia_drv_video.so
VAAPI driver: VA-API NVDEC driver [direct backend].
```

Chromium then fails to import each decoded frame, once per frame at exactly the video's frame rate (~33ms apart at 30fps):

```
ERROR:ui/gl/angle_platform_impl.cc:48] ImageEGL.cpp:118 (operator()): eglCreateImage failed with 0x00003009
ERROR:ui/gl/scoped_egl_image.cc:23] Failed to create EGLImage: EGL_SUCCESS
ERROR:ui/ozone/common/native_pixmap_egl_binding.cc:76] Unable to initialize binding from pixmap
ERROR:gpu/command_buffer/service/shared_image/ozone_image_backing.cc:320] OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation
ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:269] SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: CompoundImageBacking
```

`0x00003009` is `EGL_BAD_MATCH` — the NVDEC dmabuf cannot be bound in Chromium's Intel-backed ANGLE context. Audio is a separate pipeline, so it is unaffected. That is the user-visible symptom: **sound but no picture** on YouTube, Twitch, and any other `<video>`.

## Steps to reproduce

1. Hybrid Intel + NVIDIA laptop, Hyprland rendering on the iGPU (the default when the panel is wired to Intel).
2. Open any `<video>` in Chromium — YouTube, Twitch, or a local file.
3. Audio plays; the video region stays blank.

## Isolating it

Same page, same machine, only the env var differs. Solid-magenta test clip, screenshotted with `grim`:

| `LIBVA_DRIVER_NAME` | Result | Chromium log |
|---|---|---|
| `nvidia` (Omarchy default) | no video — screenshot shows the wallpaper through the window | `eglCreateImage` failure every frame |
| `iHD` | renders correctly | clean |
| unset | renders correctly — libva auto-selects `iHD` for `renderD129` | clean |

Unsetting it is enough, because libva already picks the right driver per device node:

```
$ env -u LIBVA_DRIVER_NAME ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD129 ...
libva: Trying to open /usr/lib/dri/iHD_drv_video.so
VAAPI driver: Intel iHD driver for Intel(R) Gen Graphics - 26.2.4
```

## Suggested fix

Set `LIBVA_DRIVER_NAME=nvidia` only when NVIDIA is actually the render device, rather than merely present. Gating on the compositor's DRM node (e.g. the render node Hyprland/aquamarine opened, or `AQ_DRM_DEVICES` when set) would cover it. Simply leaving `LIBVA_DRIVER_NAME` unset on hybrid systems is also correct — libva's per-node auto-detection already resolves to `nvidia` on the NVIDIA node and `iHD` on the Intel one.

`__GLX_VENDOR_LIBRARY_NAME=nvidia` is set from the same branch and looks like it deserves the same scrutiny, though it is not part of this symptom.

## Workaround

In `~/.config/hypr/hyprland.lua`, after the Omarchy defaults:

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

## System

- Omarchy 4.0.3-1
- Hyprland 0.56.2 (`efb5099`)
- CPU: 13th Gen Intel Core i7-13700HX
- GPU: Intel UHD Graphics 770 (`8086:4688`, i915) + NVIDIA RTX 4070 Laptop (`10de:2860`, nvidia-open 610.57.04)
- Kernel 7.2.3-arch1-3
- chromium 152.0.7977.82-1, mesa 1:26.2.2-1, libva 2.24.1-1, libva-nvidia-driver 0.0.18-1, intel-media-driver 26.2.4-1

Surfaced after a routine upgrade that moved chromium 151 -> 152; the misconfiguration predates it, but earlier Chromium appears to have fallen back to software decode and masked it.