Proof Portal

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-4827GitHub issuePublicReceived

Display flashing in Chromium on X.com on hybrid Intel+NVIDIA laptop (LIBVA_DRIVER_NAME=nvidia forces NVIDIA VA-API while Chromium renders on iGPU)

Reported by joebdrx · filed Sep 2, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #8215 (R-1472). GitHub close reason: completed.

Received and recorded verbatim. Nothing has been checked yet.

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?
Not yet mapped to any requirement or component.
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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

Display flashing in Chromium on X.com on hybrid Intel+NVIDIA laptop (LIBVA_DRIVER_NAME=nvidia forces NVIDIA VA-API while Chromium renders on iGPU)revision 1 · captured 2026-10-04 12:03 UTC via poll

name: About
about: Hybrid-GPU laptop: X.com display flashing in Chromium caused by Omarchy's global LIBVA_DRIVER_NAME=nvidia
title: 'Display flashing in Chromium on X.com on hybrid Intel+NVIDIA laptop (LIBVA_DRIVER_NAME=nvidia forces NVIDIA VA-API while Chromium renders on iGPU)'
labels: bug
assignees: ''
---

Summary

On a hybrid-graphics laptop (Intel iGPU driving the display, NVIDIA dGPU in Hybrid mode via supergfxd), Chromium exhibits rapid display flashing/flickering only on x.com (Twitter). The browser window content strobes repeatedly while video autoplays in the feed.

Root cause

Omarchy's Hyprland config (/usr/share/omarchy/default/hypr/nvidia.lua) exports session-wide env vars when an NVIDIA GPU is detected:

NVD_BACKEND=direct
LIBVA_DRIVER_NAME=nvidia
__GLX_VENDOR_LIBRARY_NAME=nvidia

These vars are appropriate for single-GPU NVIDIA systems, but on a hybrid laptop in Hybrid mode they leak into Chromium (and every other app). Chromium's GPU process renders on the Intel iGPU (--render-node-override=/dev/dri/renderD128), but LIBVA_DRIVER_NAME=nvidia forces its hardware video decoder through the NVIDIA VA-API path (libva-nvidia-driver/NVDEC on renderD129). The decoded frames must then be imported back to the iGPU compositor, and that cross-GPU buffer import fails on every video frame:

ERROR: ui/gl/angle_platform_impl.cc(47)] ImageEGL.cpp:118 (operator()): eglCreateImage failed with 0x00003009   (EGL_BAD_MATCH)
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(317)] 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

~4,500 of these errors accumulated in ~3 minutes of an X.com feed scroll — one per video frame attempt. Each failed import visually manifests as a flash. The user session journal (journalctl --user) shows the identical error signature from Chromium on x.com only; other sites' video and apps are unaffected or less noticeable because X.com autoplays many back-to-back videos while scrolling.

System info

  • Omarchy 4.0.1-1, kernel 7.1.9-arch1-2
  • Chromium 151.0.7922.173 (Arch package), Wayland/ozone-wayland, Hyprland 0.56.2
  • CPU: Intel Tiger Lake-H (iGPU: UHD Graphics, i915), dGPU: NVIDIA GTX 1650 Mobile (TU117M)
  • NVIDIA driver: nvidia-open-dkms 610.57.04, nvidia-drm.modeset=1, GSP firmware loaded
  • supergfxd 5.2.7 in Hybrid mode (dGPU on-demand; iGPU drives display)
  • libva-nvidia-driver 0.0.17, intel-media-driver 26.2.4 installed

Reproduction

  1. Omarchy on hybrid Intel+NVIDIA laptop, supergfxd in Hybrid mode (iGPU drives display).
  2. Open Chromium with X.com feed with autoplaying video.
  3. Observe rapid flashing of the browser window while videos play/scroll.

Console check: journalctl --user -b | grep 'eglCreateImage failed' fills with 0x00003009 while the flashing occurs.

Verified fix / workaround

Override the VA-API driver back to the Intel one for Chromium only (no root, no session-wide change):

env LIBVA_DRIVER_NAME=iHD chromium

With this env override, flashing stops completely and the identical X.com scroll/video session produces zero eglCreateImage errors. Hardware decode still works (via intel-media-driver on the iGPU that renders the display).

Suggested fix in Omarchy

nvidia.lua should not set LIBVA_DRIVER_NAME=nvidia (and arguably not NVD_BACKEND/__GLX_VENDOR_LIBRARY_NAME session-wide) when supergfxd is in Hybrid mode and the iGPU is driving the display. Possible approaches:

  1. Detect the active graphics mode (e.g. supergfxctl -g == Hybrid) and skip the NVIDIA VA-API env vars in that case; or
  2. Only export these vars when the NVIDIA GPU is the display-driving GPU (Integrated-mode-with-dGPU / dGPU-only setups), not in Hybrid.

Happy to test patches. Thanks for a great distro!

View raw text
---
name: About
about: Hybrid-GPU laptop: X.com display flashing in Chromium caused by Omarchy's global LIBVA_DRIVER_NAME=nvidia
title: 'Display flashing in Chromium on X.com on hybrid Intel+NVIDIA laptop (LIBVA_DRIVER_NAME=nvidia forces NVIDIA VA-API while Chromium renders on iGPU)'
labels: bug
assignees: ''
---

## Summary

On a hybrid-graphics laptop (Intel iGPU driving the display, NVIDIA dGPU in Hybrid mode via supergfxd), Chromium exhibits rapid display flashing/flickering **only on x.com (Twitter)**. The browser window content strobes repeatedly while video autoplays in the feed.

## Root cause

Omarchy's Hyprland config (`/usr/share/omarchy/default/hypr/nvidia.lua`) exports session-wide env vars when an NVIDIA GPU is detected:

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

These vars are appropriate for single-GPU NVIDIA systems, but on a **hybrid** laptop in Hybrid mode they leak into Chromium (and every other app). Chromium's GPU process renders on the Intel iGPU (`--render-node-override=/dev/dri/renderD128`), but `LIBVA_DRIVER_NAME=nvidia` forces its hardware video decoder through the NVIDIA VA-API path (`libva-nvidia-driver`/NVDEC on `renderD129`). The decoded frames must then be imported back to the iGPU compositor, and that cross-GPU buffer import fails on every video frame:

```
ERROR: ui/gl/angle_platform_impl.cc(47)] ImageEGL.cpp:118 (operator()): eglCreateImage failed with 0x00003009   (EGL_BAD_MATCH)
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(317)] 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
```

~4,500 of these errors accumulated in ~3 minutes of an X.com feed scroll — one per video frame attempt. Each failed import visually manifests as a flash. The user session journal (`journalctl --user`) shows the identical error signature from Chromium on x.com only; other sites' video and apps are unaffected or less noticeable because X.com autoplays many back-to-back videos while scrolling.

## System info

- Omarchy 4.0.1-1, kernel 7.1.9-arch1-2
- Chromium 151.0.7922.173 (Arch package), Wayland/ozone-wayland, Hyprland 0.56.2
- CPU: Intel Tiger Lake-H (iGPU: UHD Graphics, `i915`), dGPU: NVIDIA GTX 1650 Mobile (TU117M)
- NVIDIA driver: nvidia-open-dkms 610.57.04, `nvidia-drm.modeset=1`, GSP firmware loaded
- supergfxd 5.2.7 in **Hybrid** mode (dGPU on-demand; iGPU drives display)
- libva-nvidia-driver 0.0.17, intel-media-driver 26.2.4 installed

## Reproduction

1. Omarchy on hybrid Intel+NVIDIA laptop, supergfxd in Hybrid mode (iGPU drives display).
2. Open Chromium with X.com feed with autoplaying video.
3. Observe rapid flashing of the browser window while videos play/scroll.

Console check: `journalctl --user -b | grep 'eglCreateImage failed'` fills with `0x00003009` while the flashing occurs.

## Verified fix / workaround

Override the VA-API driver back to the Intel one **for Chromium only** (no root, no session-wide change):

```bash
env LIBVA_DRIVER_NAME=iHD chromium
```

With this env override, flashing stops completely and the identical X.com scroll/video session produces **zero** `eglCreateImage` errors. Hardware decode still works (via intel-media-driver on the iGPU that renders the display).

## Suggested fix in Omarchy

`nvidia.lua` should not set `LIBVA_DRIVER_NAME=nvidia` (and arguably not `NVD_BACKEND`/`__GLX_VENDOR_LIBRARY_NAME` session-wide) when supergfxd is in **Hybrid** mode and the iGPU is driving the display. Possible approaches:

1. Detect the active graphics mode (e.g. `supergfxctl -g` == `Hybrid`) and skip the NVIDIA VA-API env vars in that case; or
2. Only export these vars when the NVIDIA GPU is the display-driving GPU (Integrated-mode-with-dGPU / dGPU-only setups), not in Hybrid.

Happy to test patches. Thanks for a great distro!

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

Not linked to any known issue, other report or change yet.

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.

No decision has been recorded yet.