## Summary

On a hybrid laptop where Hyprland and Chromium composite on the Intel iGPU,
`default/hypr/nvidia.lua` exports `LIBVA_DRIVER_NAME=nvidia` and
`__GLX_VENDOR_LIBRARY_NAME=nvidia` for the whole session, based only on "an
NVIDIA GPU exists". Chromium then decodes video through NVDEC on the dGPU but
composites on the iGPU, and cannot import the decoded frames as EGLImages.

Every frame fails, and video playback collapses. Measured on this machine:
**~9 fps** (193 unique frames out of 1292 in a 21.5 s screen recording of a
Vimeo player that should run at 24–30 fps).

This affects Chromium, Brave, Edge and every Omarchy web app launched through
`omarchy-launch-webapp`, out of the box. Firefox is unaffected because it uses
native EGL with DMABUF and does not go through the GLX vendor.

## Reproduction

Hybrid laptop, Intel iGPU driving the internal panel, NVIDIA dGPU present:

```
$ lspci -nn | grep -iE "vga|3d"
00:02.0 VGA compatible controller: Intel Arrow Lake-S [8086:7d67]
02:00.0 VGA compatible controller: NVIDIA GB203M / RTX 5080 Max-Q [10de:2c59]

$ printenv LIBVA_DRIVER_NAME __GLX_VENDOR_LIBRARY_NAME
nvidia
nvidia
```

Chromium picks the iGPU to composite (as reported by `chrome://gpu`):

```
GPU0: VENDOR=0x10de, DEVICE=0x2c59, DRIVER_VENDOR=Mesa
GPU1: VENDOR=0x8086, DEVICE=0x7d67, DRIVER_VENDOR=Mesa  *ACTIVE*
Command Line: ... --render-node-override=/dev/dri/renderD129     (= the Intel)
```

Play any video. The log fills with, per frame:

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

`0x3009` is `EGL_BAD_MATCH`: the NVDEC-produced buffer cannot be imported on
the Intel device.

Launching the same Chromium with those variables removed produces **zero** EGL,
ANGLE, Ozone or Skia errors, and video plays smoothly:

```bash
env -u LIBVA_DRIVER_NAME -u NVD_BACKEND -u __GLX_VENDOR_LIBRARY_NAME chromium
```

## Root cause

`bin/omarchy-hw-nvidia` and `bin/omarchy-hw-nvidia-gsp` answer only
**"does an NVIDIA GPU exist?"** — they walk `/sys/bus/pci/devices` looking for
vendor `0x10de` with a display class. Neither asks which device actually
drives the outputs or hosts the compositor.

`default/hypr/nvidia.lua` then acts on that alone:

```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 a desktop with a single NVIDIA card this is right. On a hybrid laptop with
`nvidia-open-dkms` and the iGPU compositing, it points VA-API and the GLX
vendor at a device that is not the one presenting frames.

Note that both variables matter independently — verified by elimination on this
machine:

| Variables changed | Result |
|---|---|
| `__GLX_VENDOR_LIBRARY_NAME` unset only | still broken, same `EGL_BAD_MATCH` |
| `LIBVA_DRIVER_NAME=iHD` only | still broken |
| all three unset | clean logs, smooth playback |

## Suggested fix

Gate the exports on the NVIDIA GPU actually being the compositing/primary
device, rather than merely present. A cheap check is whether any *connected*
DRM connector belongs to the NVIDIA PCI device:

```bash
for c in /sys/class/drm/card*-*/status; do
  [[ $(< "$c") == connected ]] || continue
  v=$(< "$(dirname "$c")/../device/vendor")
  [[ $v == 0x10de ]] && exit 0     # NVIDIA drives at least one output
done
exit 1
```

On this machine that distinction is visible and unambiguous:

```
card0-eDP-2 -> INTEL    (internal panel, and what the compositor runs on)
card1-DP-1  -> NVIDIA   (external monitor)
```

Even here, with an external monitor on the NVIDIA connector, Chromium still
composites on the Intel — so "an output is wired to the dGPU" is not by itself
a reason to force VA-API onto it.

A narrower alternative: keep `__GLX_VENDOR_LIBRARY_NAME` as-is but stop
exporting `LIBVA_DRIVER_NAME` on hybrid systems, letting libva autodetect per
device. That alone was not sufficient here, so the GLX vendor needs handling
too.

Users can work around it today by overriding in their own config, which loads
after the defaults:

```lua
-- ~/.config/hypr/autostart.lua
hl.env("LIBVA_DRIVER_NAME", "iHD")
hl.env("__GLX_VENDOR_LIBRARY_NAME", "mesa")
```

## Environment

| | |
|---|---|
| Omarchy | 4.0.4-1 |
| Hyprland | 0.56.2 (`efb5099`) |
| Kernel | 7.2.5-3-omarchy |
| Machine | Lenovo Legion Pro 7 16IAX10H |
| iGPU | Intel Arrow Lake-S `8086:7d67`, Mesa 26.2.2 |
| dGPU | NVIDIA RTX 5080 Max-Q `10de:2c59`, `nvidia-open-dkms` 610.57.04 |
| Chromium | 152.0.7977.82-1 |
| Drivers | `libva-nvidia-driver`, `intel-media-driver` 26.2.4 both installed |