Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-5150GitHub issuePublicDecided· Out of scope

NVIDIA hybrid laptops: nvidia.lua's global LIBVA_DRIVER_NAME overrides the Firefox-specific iHD override

Reported by Master-Mexanikus · filed Oct 5, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

NVIDIA hybrid laptops: nvidia.lua's global LIBVA_DRIVER_NAME overrides the Firefox-specific iHD overriderevision 1 · captured 2026-10-05 00:47 UTC via poll

What happened

On a hybrid Intel+NVIDIA laptop, Firefox silently falls back to software video decoding instead of using hardware VA-API acceleration, causing high CPU usage in the "Isolated Web Content" and "RDD Process" processes during any video playback.

Root cause

Two first-party Omarchy defaults set the same environment variable and fight over it:

  1. /usr/share/omarchy/default/hypr/nvidia.lua:13 sets LIBVA_DRIVER_NAME=nvidia globally via hl.env() for the whole Hyprland session (presumably intended for mpv/other apps using the NVIDIA NVDEC VA-API driver).
  2. ~/.config/environment.d/omarchy-firefox-vaapi.conf (shipped by Omarchy) tries to override this specifically for Firefox with LIBVA_DRIVER_NAME=iHD (the Intel driver) — presumably because Firefox's RDD sandbox doesn't get along with the proprietary NVIDIA VA-API driver.

Because nvidia.lua runs at Hyprland compositor startup (after environment.d is imported at login), its value wins. systemctl --user show-environment confirms the final session value is nvidia, not the iHD that Omarchy's own Firefox override file intends. Firefox ends up launched with the NVIDIA driver, which its sandbox apparently can't use, so it falls back to software decoding.

Expected

Firefox should actually get LIBVA_DRIVER_NAME=iHD as omarchy-firefox-vaapi.conf intends, independent of nvidia.lua's global override — or the two defaults should be reconciled so they don't fight over the same variable.

Steps to reproduce

  1. Install Omarchy on a hybrid Intel+NVIDIA laptop (NVIDIA driver, not nouveau).
  2. Check systemctl --user show-environment | grep LIBVA_DRIVER_NAME — it reports nvidia, even though ~/.config/environment.d/omarchy-firefox-vaapi.conf specifies iHD.
  3. Play video in Firefox and watch CPU usage of the "Isolated Web Content" / "RDD Process" processes spike — hardware decode isn't being used.

System details

  • omarchy version: 4.0.3-1
  • CPU/iGPU: Intel Arrow Lake-S (Intel Graphics), driver i915/xe
  • Discrete GPU: NVIDIA GeForce RTX 5070 Ti Mobile, driver nvidia
  • Laptop: Acer Predator PHN16-73 (hybrid Optimus-style graphics)
  • vainfo confirms VA-API itself works fine via the NVIDIA NVDEC driver when queried directly — this is specifically about which driver Firefox's sandboxed process ends up using.

Workaround

Wrapping Firefox's launch to explicitly export LIBVA_DRIVER_NAME=iHD before exec (instead of relying on environment.d) fixes hardware decode for Firefox, confirming the diagnosis.

View raw text
## What happened

On a hybrid Intel+NVIDIA laptop, Firefox silently falls back to software video decoding instead of using hardware VA-API acceleration, causing high CPU usage in the "Isolated Web Content" and "RDD Process" processes during any video playback.

## Root cause

Two first-party Omarchy defaults set the same environment variable and fight over it:

1. `/usr/share/omarchy/default/hypr/nvidia.lua:13` sets `LIBVA_DRIVER_NAME=nvidia` globally via `hl.env()` for the whole Hyprland session (presumably intended for mpv/other apps using the NVIDIA NVDEC VA-API driver).
2. `~/.config/environment.d/omarchy-firefox-vaapi.conf` (shipped by Omarchy) tries to override this specifically for Firefox with `LIBVA_DRIVER_NAME=iHD` (the Intel driver) — presumably because Firefox's RDD sandbox doesn't get along with the proprietary NVIDIA VA-API driver.

Because `nvidia.lua` runs at Hyprland compositor startup (after environment.d is imported at login), its value wins. `systemctl --user show-environment` confirms the final session value is `nvidia`, not the `iHD` that Omarchy's own Firefox override file intends. Firefox ends up launched with the NVIDIA driver, which its sandbox apparently can't use, so it falls back to software decoding.

## Expected

Firefox should actually get `LIBVA_DRIVER_NAME=iHD` as `omarchy-firefox-vaapi.conf` intends, independent of `nvidia.lua`'s global override — or the two defaults should be reconciled so they don't fight over the same variable.

## Steps to reproduce

1. Install Omarchy on a hybrid Intel+NVIDIA laptop (NVIDIA driver, not nouveau).
2. Check `systemctl --user show-environment | grep LIBVA_DRIVER_NAME` — it reports `nvidia`, even though `~/.config/environment.d/omarchy-firefox-vaapi.conf` specifies `iHD`.
3. Play video in Firefox and watch CPU usage of the "Isolated Web Content" / "RDD Process" processes spike — hardware decode isn't being used.

## System details

- `omarchy version`: 4.0.3-1
- CPU/iGPU: Intel Arrow Lake-S (Intel Graphics), driver `i915`/`xe`
- Discrete GPU: NVIDIA GeForce RTX 5070 Ti Mobile, driver `nvidia`
- Laptop: Acer Predator PHN16-73 (hybrid Optimus-style graphics)
- `vainfo` confirms VA-API itself works fine via the NVIDIA NVDEC driver when queried directly — this is specifically about which driver Firefox's sandboxed process ends up using.

## Workaround

Wrapping Firefox's launch to explicitly `export LIBVA_DRIVER_NAME=iHD` before exec (instead of relying on environment.d) fixes hardware decode for Firefox, confirming the diagnosis.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

  • Related PRpr/9483· confirmed

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 21:26 UTC