## Summary

On a hybrid laptop where the **only connected display is driven by the Intel iGPU** and an NVIDIA dGPU is merely *present*, Omarchy's `default/hypr/nvidia.lua` exports `__GLX_VENDOR_LIBRARY_NAME=nvidia` and `LIBVA_DRIVER_NAME=nvidia` for the entire session. These force Chromium/Chrome/Brave's GPU process onto the NVIDIA EGL/VAAPI stack, which **cannot import the i915-allocated Wayland pixmaps**. Result: `eglCreateImage` fails with `EGL_BAD_ALLOC` thousands of times per minute and **all video renders black**.

The user-visible symptom is "YouTube is broken on Wayland," which makes this look like a browser or Wayland bug. It is neither — it is the NVIDIA-env block being applied without regard to which GPU actually owns the display.

## Steps to reproduce

1. On a hybrid laptop with the internal panel on the iGPU and an NVIDIA dGPU present, boot Omarchy.
2. Launch Chromium-based browser on native Wayland (e.g. `brave --ozone-platform=wayland`).
3. Play any video (YouTube or local).

Observed:

- Video area renders **black**; audio plays.
- Scrolling the page causes visible **screen shaking** (the player thrashing on failed texture uploads).
- Console shows repeating `ResizeObserver loop completed with undelivered notifications`.
- GPU process log shows a repeating 5-error block, thousands of times:

```
ERROR:ui/gl/angle_platform_impl.cc:34] ImageEGL.cpp:118: 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:275] SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: CompoundImageBacking
```

`0x3009` is `EGL_BAD_ALLOC`.

## Expected behavior

Brave/Chromium should render video normally, using the GPU that owns the display (the iGPU, which has hardware VP9/AV1 decode on this class of hardware).

Workaround that confirms the diagnosis — running the same browser with those two variables removed:

```bash
env -u __GLX_VENDOR_LIBRARY_NAME -u LIBVA_DRIVER_NAME brave --ozone-platform=wayland
```

Result: **0 errors**, video plays, and hardware video decode still active (`Video Decode: Hardware accelerated`, `GL_RENDERER = Intel Iris Xe`).

## The gap in Omarchy's logic

`default/hypr/nvidia.lua` gates on **GPU presence**, not on **which GPU drives the display**:

```
$ cat /usr/share/omarchy/bin/omarchy-hw-nvidia-gsp
  vendor 0x10de, class 0x03, device >= 0x1e00   -> "is an NVIDIA GPU PRESENT?"
```

It never inspects DRM connectors or scanout ownership. On this machine it matches, so:

```lua
hl.env("NVD_BACKEND", "direct")
hl.env("LIBVA_DRIVER_NAME", "nvidia")
hl.env("__GLX_VENDOR_LIBRARY_NAME", "nvidia")
```

are exported session-wide.

Meanwhile Omarchy **already ships a hybrid-GPU detector** that returns true here:

```
$ /usr/share/omarchy/bin/omarchy-hw-hybrid-gpu   # -> HYBRID DETECTED
```

but it is referenced from exactly one place, a menu entry:

```
default/omarchy/omarchy-menu.jsonc:71
  "trigger.hardware.hybrid-gpu" -> action: "omarchy-toggle-hybrid-gpu"
```

and its result is never consulted by `nvidia.lua`. The two features were never connected.

Note that `omarchy-toggle-hybrid-gpu` (MUX switching via `supergfxctl`) is also not applicable to all hybrid machines — this laptop has **no `supergfxctl`** and no switchable MUX, so that menu action cannot help here.

## Why XWayland appears to work

Forcing `--ozone-platform=x11` avoids the problem entirely, because XWayland falls back to a CPU copy between client and compositor instead of zero-copy dma-buf, and `memcpy` is vendor-agnostic. This is why the bug tends to get misdiagnosed as "Wayland is broken."

(That workaround has its own cost: XWayland ignores Hiprland's scale for cursor rendering, so cursors over XWayland windows are visibly blurry on a HiDPI panel. That's what prompted the investigation.)

## Requested fix

One of:

1. **Gate the NVIDIA env block on display ownership** — only export `__GLX_VENDOR_LIBRARY_NAME` / `LIBVA_DRIVER_NAME` when an NVIDIA GPU actually owns a connected connector (or is the only GPU). This is the smallest change and preserves current behavior on single-GPU / dGPU-primary machines, where the vars are correct and important.
2. **Wire `omarchy-hw-hybrid-gpu` into `nvidia.lua`** so the env block is skipped or altered on hybrid laptops with the panel on the iGPU.

Ideally the env decision would be driven by which GPU is rendering, which the compositor already knows.

## Note on which variable is actually required

I verified that removing **both** variables fixes it. I did **not** isolate whether removing only one is sufficient — the error counts across runs are noisy (2298 / 3806 / 7778 depending on run length) and are not a reliable signal of causality. A maintainer narrowing this down would need a controlled single-variable test. I mention it so nobody reads the workaround as proof that both are independently necessary.

## System details

```
Omarchy:        4.0.4-1
Kernel:         7.2.5-3-omarchy
Hyprland:       0.56.2
Machine:        ASUSTeK Vivobook_ASUSLaptop K6602VV
CPU:            Intel Core i9-13900H (Raptor Lake)
GPU 1 (display): Intel Iris Xe (Raptor Lake-P), driver i915
GPU 2:           NVIDIA GeForce RTX 4060 Max-Q (AD107M), driver nvidia
Panel:           Samsung 0x4178, eDP-2, 3200x2000, connected
                 -> owned by i915; all nvidia card1 outputs (DP-1,
                    eDP-1, HDMI-A-1) are disconnected
Browser:        Brave 154.1.96.59 (Chrome/154.0.8037.58)
nvidia driver:  nvidia-open-dkms 610.57.04-1
intel VAAPI:    intel-media-driver 26.2.4-1
MUX:            none (no supergfxctl)
```

Full diagnostic log available on request (`omarchy-debug --no-sudo --print`).