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

Hybrid Intel+NVIDIA: Chromium hardware acceleration requires manual workarounds

Reported by josefdc · filed Mar 4, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #2800 (R-2062). 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

Hybrid Intel+NVIDIA: Chromium hardware acceleration requires manual workaroundsrevision 1 · captured 2026-10-04 11:49 UTC via poll

System details

  • CPU: 13th Gen Intel (Raptor Lake-P)
  • GPU (integrated): Intel Iris Xe Graphics (RPL-P)
  • GPU (discrete): NVIDIA GeForce RTX 3050 6GB Laptop GPU
  • Drivers: nvidia-open-dkms 590.48.01, Mesa 26.0.1, intel-media-driver 25.3.4
  • Omarchy: 3.4.1
  • Kernel: 6.18.13-arch1-1
  • Chromium: 145.0.7632.116

Problem

On hybrid Intel+NVIDIA laptops, Chromium's hardware acceleration is broken out of the box. Enabling "Use hardware acceleration when available" in Chromium settings causes black screen, flickering, and visual corruption. This forces users to disable hardware acceleration entirely, losing VAAPI video decode and GPU rasterization.

The root cause is a cross-GPU DMA-BUF incompatibility: Hyprland's compositor runs on the NVIDIA GPU, while Chromium renders via the Intel GPU through ANGLE/OpenGL. When Chromium's GPU compositor tries to import NVIDIA DMA-BUF buffers as EGLImages on the Intel GPU, it fails with EGL_BAD_MATCH (0x3009), producing hundreds of errors per second:

eglCreateImage failed with 0x00003009
OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation
SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: OzoneImageBacking

This is the same issue reported in #3899 (same hardware: 13th Gen Intel + RTX 3050).

Investigation & what we tried

1. Set LIBVA_DRIVER_NAME=iHD in ~/.config/hypr/envs.conf

Result: Partially successful. Without this, vainfo defaults to NVIDIA's NVDEC driver which has limited VAAPI support. With iHD, Intel's full VAAPI stack activates (60+ profiles including H264, VP9, HEVC, AV1 encode/decode).

2. Added VA-API flags to chromium-flags.conf (as proposed in #4773)

--enable-features=VaapiVideoDecodeLinuxGL,VaapiVideoEncoder
--enable-gpu-rasterization
--enable-zero-copy
--ignore-gpu-blocklist

Result: Partially successful. chrome://gpu showed "Video Decode: Hardware accelerated" and chrome://media-internals confirmed VaapiVideoDecoder was being used. However, the eglCreateImage errors persisted, causing black screen and flickering.

3. Tried --use-angle=vulkan with Vulkan features

--use-angle=vulkan
--enable-features=Vulkan,DefaultANGLEVulkan

Result: Failed. Chromium window became completely transparent/invisible. ANGLE Vulkan cannot render at all on this hybrid setup.

4. Added --disable-gpu-compositing (working solution)

--disable-gpu-compositing

Result: Working workaround. This disables only the GPU compositor (the part that does cross-GPU buffer sharing), while keeping:
- ✅ VAAPI video decode (hardware) - H264, VP8, VP9, HEVC, AV1
- ✅ GPU rasterization (hardware)
- ✅ Canvas (hardware)
- ✅ WebGL/WebGPU (hardware, at reduced performance)
- ❌ GPU compositing (software - scrolling/CSS animations use CPU)

Working configuration

~/.config/hypr/envs.conf

env = LIBVA_DRIVER_NAME,iHD

~/.config/chromium-flags.conf

--enable-features=VaapiVideoDecodeLinuxGL,VaapiVideoEncoder
--enable-gpu-rasterization
--enable-zero-copy
--ignore-gpu-blocklist
--disable-gpu-compositing

Proposal

For hybrid Intel+NVIDIA systems, Omarchy could:

  1. Auto-detect hybrid GPU setups and set LIBVA_DRIVER_NAME=iHD in the environment (needed for Intel VAAPI to work when NVIDIA is present)
  2. Include VA-API flags by default in chromium-flags.conf (as proposed in #4773)
  3. Auto-add `--disable-gpu-compositing` for hybrid Intel+NVIDIA systems to prevent the cross-GPU eglCreateImage errors

This would make Chromium usable with hardware acceleration out of the box on hybrid laptops, instead of forcing users to either disable HW acceleration entirely or manually figure out the workaround.

Related issues

  • #4773 — Enable VA-API hardware acceleration in default Chromium flags
  • #3899 — Chromium GPU/Ozone errors after update to 3.2.3 (same hardware, same errors)
  • #2964 — Chromium crashes when hardware acceleration is enabled
  • #2800 — google-chrome flickers
  • #3891 — Videos not playing after recent update
View raw text
## System details

- **CPU:** 13th Gen Intel (Raptor Lake-P)
- **GPU (integrated):** Intel Iris Xe Graphics (RPL-P)
- **GPU (discrete):** NVIDIA GeForce RTX 3050 6GB Laptop GPU
- **Drivers:** nvidia-open-dkms 590.48.01, Mesa 26.0.1, intel-media-driver 25.3.4
- **Omarchy:** 3.4.1
- **Kernel:** 6.18.13-arch1-1
- **Chromium:** 145.0.7632.116

## Problem

On hybrid Intel+NVIDIA laptops, Chromium's hardware acceleration is broken out of the box. Enabling "Use hardware acceleration when available" in Chromium settings causes **black screen, flickering, and visual corruption**. This forces users to disable hardware acceleration entirely, losing VAAPI video decode and GPU rasterization.

The root cause is a **cross-GPU DMA-BUF incompatibility**: Hyprland's compositor runs on the NVIDIA GPU, while Chromium renders via the Intel GPU through ANGLE/OpenGL. When Chromium's GPU compositor tries to import NVIDIA DMA-BUF buffers as EGLImages on the Intel GPU, it fails with `EGL_BAD_MATCH (0x3009)`, producing hundreds of errors per second:

```
eglCreateImage failed with 0x00003009
OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation
SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: OzoneImageBacking
```

This is the same issue reported in #3899 (same hardware: 13th Gen Intel + RTX 3050).

## Investigation & what we tried

### 1. Set `LIBVA_DRIVER_NAME=iHD` in `~/.config/hypr/envs.conf`
**Result: Partially successful.** Without this, `vainfo` defaults to NVIDIA's NVDEC driver which has limited VAAPI support. With `iHD`, Intel's full VAAPI stack activates (60+ profiles including H264, VP9, HEVC, AV1 encode/decode).

### 2. Added VA-API flags to `chromium-flags.conf` (as proposed in #4773)
```
--enable-features=VaapiVideoDecodeLinuxGL,VaapiVideoEncoder
--enable-gpu-rasterization
--enable-zero-copy
--ignore-gpu-blocklist
```
**Result: Partially successful.** `chrome://gpu` showed "Video Decode: Hardware accelerated" and `chrome://media-internals` confirmed `VaapiVideoDecoder` was being used. However, the `eglCreateImage` errors persisted, causing **black screen and flickering**.

### 3. Tried `--use-angle=vulkan` with Vulkan features
```
--use-angle=vulkan
--enable-features=Vulkan,DefaultANGLEVulkan
```
**Result: Failed.** Chromium window became completely transparent/invisible. ANGLE Vulkan cannot render at all on this hybrid setup.

### 4. Added `--disable-gpu-compositing` (working solution)
```
--disable-gpu-compositing
```
**Result: Working workaround.** This disables only the GPU compositor (the part that does cross-GPU buffer sharing), while keeping:
- ✅ VAAPI video decode (hardware) - H264, VP8, VP9, HEVC, AV1
- ✅ GPU rasterization (hardware)
- ✅ Canvas (hardware)
- ✅ WebGL/WebGPU (hardware, at reduced performance)
- ❌ GPU compositing (software - scrolling/CSS animations use CPU)

## Working configuration

### `~/.config/hypr/envs.conf`
```
env = LIBVA_DRIVER_NAME,iHD
```

### `~/.config/chromium-flags.conf`
```
--enable-features=VaapiVideoDecodeLinuxGL,VaapiVideoEncoder
--enable-gpu-rasterization
--enable-zero-copy
--ignore-gpu-blocklist
--disable-gpu-compositing
```

## Proposal

For hybrid Intel+NVIDIA systems, Omarchy could:

1. **Auto-detect hybrid GPU setups** and set `LIBVA_DRIVER_NAME=iHD` in the environment (needed for Intel VAAPI to work when NVIDIA is present)
2. **Include VA-API flags by default** in `chromium-flags.conf` (as proposed in #4773)
3. **Auto-add `--disable-gpu-compositing`** for hybrid Intel+NVIDIA systems to prevent the cross-GPU `eglCreateImage` errors

This would make Chromium usable with hardware acceleration out of the box on hybrid laptops, instead of forcing users to either disable HW acceleration entirely or manually figure out the workaround.

## Related issues

- #4773 — Enable VA-API hardware acceleration in default Chromium flags
- #3899 — Chromium GPU/Ozone errors after update to 3.2.3 (same hardware, same errors)
- #2964 — Chromium crashes when hardware acceleration is enabled
- #2800 — google-chrome flickers
- #3891 — Videos not playing after recent update

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.