# Chromium flickers, plays black video, or loses hardware acceleration
Chromium flicker, black video, or lost hardware acceleration on Omarchy 4.x hybrid laptops: point LIBVA_DRIVER_NAME at the GPU that drives your screen.
> **Short answer:** On a hybrid laptop whose screen runs off the integrated GPU, Omarchy points the whole session at the NVIDIA VA-API driver, so video decodes on the dGPU and fails to import on the iGPU. Add hl.env("LIBVA_DRIVER_NAME", "iHD") (or "radeonsi" on AMD) to ~/.config/hypr/hyprland.lua, run systemctl --user set-environment with the same value, then restart the browser. Still open on 4.0.4.
- Applies to Omarchy: 3.x and later
- Status: workaround
- Last verified: 2026-09-16
- Canonical: https://omarchylinux.org/fix/chromium-flicker-hardware-acceleration/
_Unofficial community page. Not affiliated with 37signals or the Omacom Foundation. Omarchy is a registered trademark of 37signals LLC._

If your browser flickers, shows a black rectangle where the video should be, or drops to software rendering, and you have a laptop with both an integrated GPU and an NVIDIA card, this is almost certainly one bug. Omarchy points the whole session at the NVIDIA VA-API driver whenever an NVIDIA GPU is present, even when your screen is driven by the integrated GPU. Video then decodes on the discrete card and cannot be imported for display on the integrated one.

## The fix

**1. Confirm you are affected.** In a terminal:

```bash
systemctl --user show-environment | grep -E 'LIBVA_DRIVER_NAME|NVD_BACKEND'
```

If that prints `LIBVA_DRIVER_NAME=nvidia` and your laptop panel is wired to the integrated GPU, you have it. Check which card owns the panel with:

```bash
for c in /sys/class/drm/card*-*/status; do echo "$c $(cat "$c")"; done
```

**2. Pick the right driver name.** Intel graphics that Omarchy's installer pairs with `intel-media-driver` (HD Graphics, Iris, Xe, Arc) use `iHD`. Older Intel generations that get `libva-intel-driver` use `i965`. An AMD integrated GPU uses `radeonsi`.

**3. On 4.0.0 through 4.0.4**, add one line at the bottom of `~/.config/hypr/hyprland.lua`, below the `require` lines. Your file loads after Omarchy's defaults, and the later `env` wins:

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

**4. Apply it without logging out**, then restart the browser:

```bash
systemctl --user set-environment LIBVA_DRIVER_NAME=iHD
omarchy restart shell
```

`Super + Shift + Return` runs `omarchy-launch-browser`, which starts the browser as a user systemd unit through `uwsm-app`, so it picks up whatever `set-environment` put in the user manager. The shell's app menu hands its own environment to anything it launches, which is why Rookie0ne recommends restarting it too. Do not rely on `hyprctl reload` alone: Hyprland applies `env` at launch, and SisyphusOfCorinth confirmed on issue 8215 that reloading the config leaves the session variable as it was. An already running browser keeps its old environment until you close every window. Log out and back in if you want the clean version.

**On 3.x** the same variables were written once at install time into `~/.config/hypr/envs.conf` by the NVIDIA install step, as plain `env = LIBVA_DRIVER_NAME,nvidia` lines. Edit or delete the line there. Note that the `hyprland.conf` template shipped in later 3.x releases sources Omarchy's own `envs.conf`, not yours, so if your edit has no effect, put `env = LIBVA_DRIVER_NAME,iHD` at the bottom of `~/.config/hypr/hyprland.conf` instead.

**5. If video now plays but the window still flickers or goes black, or if hardware decode disappeared entirely after step 3**, you have the second, separate half: Chromium rendering on the NVIDIA GPU while Hyprland composites on the integrated one. Rookie0ne measured the second symptom on Google Chrome: with VA-API moved to Intel while rendering stayed on NVIDIA EGL, no VA driver loaded at all and VP9 fell back to software. josefdc's fix in issue 4901 is a wrapper that forces Mesa EGL for the browser only:

```bash
mkdir -p ~/.local/bin
cat > ~/.local/bin/chromium <<'EOF'
#!/bin/bash
export __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json
export LIBVA_DRIVER_NAME=iHD
exec /usr/bin/chromium "$@"
EOF
chmod +x ~/.local/bin/chromium
```

Do not export `__EGL_VENDOR_LIBRARY_FILENAMES` session wide. josefdc reports Hyprland then fails to initialise EGL at startup and you recover from a TTY.

To make launchers use the wrapper, copy `/usr/share/applications/chromium.desktop` to `~/.local/share/applications/` and point `Exec` at the absolute path of the wrapper. Keep the first word of `Exec` a real program: `omarchy-launch-browser` reads that first token out of the desktop file, so an `Exec=env VAR=x /usr/bin/chromium` line makes `Super + Shift + Return` do nothing. rvalue reported exactly that on issue 4901.

**6. The blunt fallback.** Adding `--disable-gpu-compositing` to `~/.config/chromium-flags.conf` stopped the corruption for the reporters who tried it, at the cost of software compositing and the fan noise that comes with it. The equivalent files are `~/.config/brave-flags.conf`, `~/.config/chrome-flags.conf` and `~/.config/microsoft-edge-stable-flags.conf`. Brave Origin reads `~/.config/brave-origin-flags.conf`, not `brave-flags.conf`, which is why the workaround looks like it failed if you only edited Brave's file.

## Verify it worked

```bash
vainfo | grep 'Driver version'
```

You want `Intel iHD driver` or the Mesa Gallium line for radeonsi, not `VA-API NVDEC driver`. Bear in mind that `vainfo` inherits the same variable you just set, so it proves the override took, not that the browser is using it.

Then open `chrome://gpu`. Video Decode and Compositing should both read "Hardware accelerated", but Rookie0ne found the top table can say that while no encoder exists, so trust the "Video Acceleration Information" table further down. For a live test, scroll a feed with autoplaying video, which is where most reporters first saw it. If you want the decoder's own account, launch with `chromium --vmodule=*vaapi*=2` and watch for a repeating `vaEndPicture failed` construct and teardown loop. That loop disappearing is the signal.

## Why it happens

`default/hypr/nvidia.lua` sets `NVD_BACKEND=direct`, `LIBVA_DRIVER_NAME=nvidia` and `__GLX_VENDOR_LIBRARY_NAME=nvidia` whenever `omarchy-hw-nvidia-gsp` finds an NVIDIA display device with a Turing or newer device ID. The detector asks whether such a card exists, not whether it drives a screen. `autostart.lua` then exports the session environment with `systemctl --user import-environment`, so every app inherits it. On a hybrid laptop each frame is decoded on the NVIDIA card and imported into an integrated GPU GL context as a DMA-BUF, which fails with `EGL_BAD_MATCH`. karluiz traced that chain in issue 8989, and ArghyaRanjanDas showed the same failure with an AMD integrated GPU, where radeonsi cannot import NVIDIA vendor modifiers.

The reason this arrived as a 4.0.1 regression, with nothing GPU related in the release notes, is subtler. `nvidia.lua` is byte-identical from 4.0.0 to 4.0.4, which I checked against the tagged sources. What changed in 4.0.1 was `o.shell_succeeds` in `default/hypr/helpers.lua`, rewritten from `os.execute` to `io.popen` with an `OK` marker, because inside the compositor `os.execute` never got a usable exit status back. That repair made the NVIDIA detector actually fire for the first time. SisyphusOfCorinth documented the attribution, and AharonG298 confirmed it independently through the edge channel.

Rookie0ne added a useful correction: libva is not the problem. With the variable unset it picks the right driver per render node on its own.

The second half is GLVND. NVIDIA's EGL vendor file has priority 10 against Mesa's 50, so Chromium loads NVIDIA EGL by default, which is why the rendering side needs its own override.

## If that did not work

- **Single-GPU NVIDIA desktop.** This is a different problem. Issue 5372 tracks lockups on media-heavy pages with `NVRM: dmaAllocMapping_GM107: can't alloc VA space for mapping` in the journal, and it is still open with no accepted fix.
- **Still on 3.x with `SharedImageManager` and `eglCreateImage` spam.** That is issue 3899, and its reporter said the problem cleared on 3.4.0, which also carried Chromium Wayland colour manager flag changes. Update before you chase flags, and see [upgrading 3 to 4](/upgrade/3-to-4-quattro/).
- **Your flags vanished after an update.** `omarchy refresh chromium` overwrites `~/.config/chromium-flags.conf` with the Omarchy default and leaves your old file as `~/.config/chromium-flags.conf.bak.<timestamp>`.
- **Browser version matters.** daedalus-codes needed `--disable-gpu-compositing` on Brave 1.94 (Chromium 152) on hardware where Brave 1.93.138 was fine without it. If a browser update broke a previously working setup, that is a plausible cause.
- **Every app is black, not just the browser.** Then this is not your bug. Start at [hybrid GPU black screen](/fix/hybrid-gpu-laptop-black-screen-aq-drm-devices/).

Evidence for the workaround is strong: Intel and AMD integrated GPUs paired with several NVIDIA generations across these threads, with before and after measurements. Evidence that any 4.0.x release fixed it is absent.

## Related

- [Hybrid GPU laptop black screen](/fix/hybrid-gpu-laptop-black-screen-aq-drm-devices/)
- [NVIDIA drivers on Omarchy 4](/fix/nvidia-drivers-omarchy-4/)
- [Hybrid GPU hardware notes](/hardware/hybrid-gpu/)
- [Intel GPU hardware notes](/hardware/intel-gpu/)
- [Still broken on the latest release](/releases/still-broken/)
- [Omarchy manual: Browsers](https://omarchy.org/manual/browsers/)

## Sources

- [Issue #8215: 4.0.1: `shell_succeeds` fix enables NVDEC VAAPI routing on hybrid laptops with Intel-driven displays, corrupting browser video](https://github.com/omacom/omarchy/issues/8215)
- [Issue #4901: Hybrid Intel+NVIDIA: Chromium hardware acceleration requires manual workarounds](https://github.com/omacom/omarchy/issues/4901)
- [Issue #7851: Don't force the NVIDIA VA-API driver on hybrid-GPU systems](https://github.com/omacom/omarchy/issues/7851)
- [Issue #8989: Hybrid iGPU-primary laptops: nvidia.lua forces NVIDIA env session-wide, video corruption (root cause of #4901) and blocked dGPU runtime suspend](https://github.com/omacom/omarchy/issues/8989)
- [Issue #8726: Hybrid AMD+NVIDIA laptop: forcing LIBVA_DRIVER_NAME=nvidia breaks all hardware-decoded video (black video players)](https://github.com/omacom/omarchy/issues/8726)
- [Issue #9483: Only point the session at NVIDIA when NVIDIA is driving the screen](https://github.com/omacom/omarchy/issues/9483)
- [Issue #8328: nvidia.lua forces LIBVA_DRIVER_NAME=nvidia on hybrid laptops where the dGPU drives no displays](https://github.com/omacom/omarchy/issues/8328)
- [Issue #3899: Chromium GPU/Ozone errors after update to 3.2.3](https://github.com/omacom/omarchy/issues/3899)
- [Issue #5372: Brave/Chromium lock up and performance glitches](https://github.com/omacom/omarchy/issues/5372)
- [default/hypr/nvidia.lua in v4.0.4](https://github.com/omacom/omarchy/blob/v4.0.4/default/hypr/nvidia.lua)
- [Omarchy manual: Browsers](https://omarchy.org/manual/browsers/)