### System details

Laptop: HP Victus by HP Laptop 16-d1xxxCPU/GPU: i7-12700H, Intel Iris Xe (iGPU, runs the compositor) + NVIDIA RTX 3060 Mobile (dGPU)DRM: card1 = nvidia 10DE:2520, card2 = i915 8086:46A6omarchy 4.0.4-1hyprland 0.56.2-2 (branch v0.56.2, commit efb50993780079460b0cbed1363e2166a2de1d9f)mesa 1:26.2.2-1nvidia-open-dkms 610.57.04-1libva 2.24.1-1libva-nvidia-driver 0.0.18-1intel-media-driver 26.2.4-1kernel 7.2.3-arch1-3brave 153.1.95.104chromium 152.0.7977.82

### What's wrong?

This report was drafted with the help of an AI assistant (Claude Code), at the request of the person filing it. All of the diagnostics, measurements and log excerpts below were produced on the affected machine.

---

`default/hypr/nvidia.lua` sets the following for the whole session on any machine where an NVIDIA GPU is detected:

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

On a hybrid laptop that forces every app to decode video via VA-API on the dGPU. But Hyprland composites on the **iGPU**, so frames are decoded on one GPU and drawn on another, and Chromium's zero-copy import into the GL context fails. Result: corrupted video in every Chromium/Electron app.

The failure is in the import, not in decoding — no VA-API or codec errors are ever logged, only Chromium/EGL ones. `eglinfo` confirms the split: the Wayland platform that every Hyprland client renders through is Intel, while a separate NVIDIA EGL device is also present.

```
Wayland platform:
  EGL driver name: iris
  OpenGL ES renderer: Mesa Intel(R) Iris(R) Xe Graphics (ADL GT2)
Surfaceless platform:
  OpenGL ES renderer: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2
```

So decode is driven onto the NVIDIA device while the render context is Intel: `eglCreateImage` gets an NVIDIA pixmap in an Intel context, which is what `EGL_BAD_MATCH` means here.

The key clue is that native players are unaffected — mpv, ffmpeg and Totem play the same files correctly because they never hit the broken import. That pointed at the GPU mismatch rather than at codecs.

### What it looks like

Video renders as random blocks of garish, unrelated colour — pink, white, magenta, red, blue, green and yellow, all mixed together with black. Audio often still plays, incoming Discord screen shares are corrupted the same way, and page scrolling tears.

The artifact is not stable, which is worth mentioning so nobody dismisses it. Coloured noise came first; a solid black picture only appeared later, after a first fix attempt that had not actually taken effect, having been written to a config file Hyprland no longer reads. The black screen is a second symptom, not the original — but the same `0x3009` failure underneath, and the same fix clears both.

`chrome://gpu` is no help: it reports `Video Decode: Hardware accelerated` and a correct-looking Intel GL renderer, so nothing appears misconfigured.

### The errors

Every video frame produces this in the GPU process (`0x3009` is `EGL_BAD_MATCH`):

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

Roughly 600 `native_pixmap_egl_binding` failures per 10 seconds of playback.

### Steps to reproduce

1. On a hybrid laptop where Hyprland composites on the iGPU, log in and check `echo $LIBVA_DRIVER_NAME` — it prints `nvidia`.
2. Play any H.264 or VP9 video in Chromium, Brave or Vesktop.
3. Observe the corrupted output above.
4. Play the same file in mpv, which works fine.

A fresh install is not required. The machine this was reported from has run Omarchy for roughly a year and worked the whole time, so this is not a new-setup problem — it is the default state on this hardware.

### Confirming the cause

Overriding the variable to the iGPU that is actually rendering fixes it completely, with no loss of hardware acceleration:

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

Verified by decoding a solid-green 1080p H.264 clip and reading pixel values back out of the page, rather than trusting the absence of errors:

| `LIBVA_DRIVER_NAME ` | decoded pixels | average RGB	| `native_pixmap` errors |
|---|---|---|---|
| `nvidia` (Omarchy default) | 0% green — black | `[0, 0, 0]` | 234 |
| `iHD` | 100% green | `[0, 128, 0]` | 0 |

Same in Chromium and Vesktop. CPU during 1080p playback was unchanged at ~10% of one core, confirming VA-API hardware decoding stays active rather than falling back to software. Forcing software decode with `--disable-accelerated-video-decode` also clears the errors but pushes CPU to ~51%, so the driver override is clearly better.

Precisely: this shows the failure is in the import, since errors and bad pixels appear and disappear together with the variable. It does not prove the NVIDIA decoder was producing correct frames — with `nvidia` set, frames never reached the screen and could not be sampled. The decode output may be fine, but this report has not measured it.

**Scope of the test:** only `LIBVA_DRIVER_NAME` was overridden; `NVD_BACKEND` and `__GLX_VENDOR_LIBRARY_NAME` were left alone. Since correcting that one variable gave fully correct video and zero errors, neither of the others is required for the import to work. They were not tested individually, so whether they are also wrong here or merely harmless is open.

### When this started

The hardware and config are not new, so something in the stack changed. The obvious suspect is ruled out: **Omarchy's config did not change** — `default/hypr/nvidia.lua` is byte-for-byte identical between omarchy 4.0.2 and 4.0.4 (diffed from the cached packages). Whatever changed is below Omarchy:

| Date | Change | Relevance |
|---|---|---|
| 2026-09-06 |	`mesa` 26.1.5 → 26.2.1 | EGL import path |
| 2026-09-06 |	`nvidia-open-dkms` 610.43.03 → 610.57.04 | dGPU driver |
| 2026-09-06 |	`intel-media-driver` 26.1.5 → 26.2.4 | the working path |
| 2026-09-19 |	**`libva-nvidia-driver` 0.0.17 → 0.0.18** | **most likely culprit** |
| 2026-09-19 |	`mesa` 26.2.1 → 26.2.2 | same day as above |
| 2026-09-19 |	`hyprland` 0.56.2-1 → 0.56.2-2	| packaging bump |

`libva-nvidia-driver` is the most interesting — it is the NVIDIA VA-API implementation itself, and moved the same day as the `mesa` bump. A change there could break cross-GPU pixmap export while leaving local NVIDIA decode working. `mesa` is the other candidate: the failing call is in the EGL/DMABUF native-pixmap import path, which may now return `EGL_BAD_MATCH` for a mismatch that previously failed silently.

**This has not been bisected** — treat the table as a shortlist, not a conclusion. The old packages are still in the pacman cache, so a bisect is straightforward if it would help. Happy to do it and report back.

### Suggested fix

`LIBVA_DRIVER_NAME=nvidia` is only correct when the session renders on the NVIDIA GPU; where Hyprland picked the iGPU it is guaranteed wrong. Gating it on the renderer Hyprland actually initialised, rather than on merely detecting an NVIDIA card, would fix this at the source. The same question applies to the other two lines in that file.

### A note on `omarchy debug`

Deliberately not attached: it contains hostname, username, network config and a full package list, which do not belong in a public issue. Everything relevant is in the field above. If a raw log would help, say so and I will post a redacted version.

### Workaround for anyone affected

Set `LIBVA_DRIVER_NAME=iHD` after Omarchy's defaults load. One gotcha: on current installs `hyprland.conf` is not read at all, since the config is now Lua, so putting this in `envs.conf` does nothing. It must go in `~/.config/hypr/hyprland.lua`, after `require("default.hypr.omarchy")` or it gets overwritten.

**Note from user:** i had this problem for couple of days but did't need to fix it till today were i opend youtube and found that the same problem that happen in vesktop also happen in youtube in brave so i opend the agent opencode and told him the problem and he went to find the problem and fixed it so i told him to make a report to send it in the github and i don't know why he called himself as claude code and not opencode and made make sure nothing can harm me be in the report anyway if there anything needed i will be happy to help