### Summary

On a hybrid Intel iGPU + NVIDIA dGPU laptop, Omarchy forces VA-API onto the NVIDIA GPU (`LIBVA_DRIVER_NAME=nvidia`) whenever any NVIDIA GPU is present. Because the browser renders on the Intel iGPU, NVIDIA-decoded video frames cannot be imported into the Intel EGL context, which kills the browser's GPU process and makes video playback (e.g. YouTube) take down the whole browser.

### System details

- Omarchy: 4.0.4-1
- Kernel: 7.2.5-3-omarchy
- Hyprland: 0.56.2
- CPU: Intel Core Ultra 7 155H
- GPU 0 (display/render): Intel Meteor Lake-P [Intel Arc Graphics] `8086:7d55` (i915, render node `renderD129`)
- GPU 1 (discrete): NVIDIA RTX 500 Ada Generation Laptop GPU `10de:28ba` (nvidia 610.57.04)
- Mesa: 1:26.2.2-1
- Reproduced with Vivaldi 8.2.4133.47 (Chromium-based; also applies to Chrome/Chromium/Edge/Brave)

### What happened

Starting a YouTube video crashes the entire browser. Diagnostics show the GPU process trying to use VA-API on NVIDIA and failing to import the decoded frames into the Intel render context:

```
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`: an NVIDIA dmabuf cannot be bound to the Intel EGL display.

### Root cause

`/usr/share/omarchy/default/hypr/nvidia.lua` runs `omarchy-hw-nvidia` / `omarchy-hw-nvidia-gsp` and, if any NVIDIA GPU with GSP is detected, exports globally:

```
NVD_BACKEND=direct
LIBVA_DRIVER_NAME=nvidia
__GLX_VENDOR_LIBRARY_NAME=nvidia
```

This detector does not check whether the NVIDIA GPU is the one actually rendering. On hybrid laptops that render on the Intel iGPU, forcing `LIBVA_DRIVER_NAME=nvidia` routes hardware video decode to the dGPU, whose dmabufs cannot be shared into the iGPU's EGL/GL context. Any Chromium-based browser then fails on video playback.

### Steps to reproduce

1. Install Omarchy on a hybrid Intel iGPU + NVIDIA dGPU laptop (NVIDIA present but Intel is the render GPU).
2. `systemctl --user show-environment | grep LIBVA` → `LIBVA_DRIVER_NAME=nvidia`
3. Open a YouTube video in Vivaldi/Chrome/Chromium.
4. Browser GPU process crashes / video playback fails.

### Evidence (A/B test, same machine, same video)

Throwaway browser profile, `--autoplay-policy=no-user-gesture-required`:

| Metric | `LIBVA_DRIVER_NAME=nvidia` | `LIBVA_DRIVER_NAME=iHD` |
| --- | --- | --- |
| `eglCreateImage failed 0x3009` | 826 | 0 |
| `Unable to initialize binding` | 413 | 0 |
| Playback | GPU process dies | plays normally |

### Expected behavior

Video playback should work out of the box on hybrid Intel-primary systems.

### Suggested fix

Only apply the NVIDIA VA-API/GLX environment when the NVIDIA GPU is actually the primary/render GPU, or don't force `LIBVA_DRIVER_NAME` on hybrid systems and let libva auto-select the decoder for the render node in use.

### Workaround

Override in the user's Hyprland config (loaded after Omarchy's defaults) so it wins over `nvidia.lua`:

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

Then `hyprctl reload` and restart the session (or `omarchy restart shell` + restart the browser) so launched apps pick up the new environment.

---
Generated with assistance from an AI agent; diagnosis and A/B evidence verified on the reporter's machine.