Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Grey-screen video playback in Chromium/Discord on hybrid AMD+NVIDIA (forced LIBVA_DRIVER_NAME=nvidia)
Reported by RibatTRW · filed Sep 7, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #8215 (R-1472). GitHub close reason: completed.
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
Symptoms
- Clicking a video (MP4) in the Discord app shows a grey screen.
- Video also fails in the system default browser (Chromium) and outside the
browser (system-wide, not Discord-only). Firefox works.
- YouTube in general also seems to crash.
Fix PR: https://github.com/omacom/omarchy/pull/10589
System details
- Omarchy 4.0.2, Hyprland 0.56.2, Wayland session.
- Hybrid laptop: NVIDIA AD107M [GeForce RTX 4060 Max-Q Mobile] + AMD
HawkPoint iGPU. Display (eDP-2) driven by the AMD side.
- Chromium 151.0.7922.173 (Discord runs as a Chromium --app webapp,
omarchy-launch-webapp https://discord.com/channels/@me, no extra flags),
Firefox 154.0, ffmpeg 9.0.1, mesa 26.2.1, nvidia 610.57.04,
libva-nvidia-driver 0.0.17.
- Session env (set by Omarchy, not user config):
LIBVA_DRIVER_NAME=nvidia, __GLX_VENDOR_LIBRARY_NAME=nvidia,
NVD_BACKEND=direct (from default/hypr/nvidia.lua, GSP branch).
- Chromium GPU process runs with --render-node-override=/dev/dri/renderD129
(AMD iGPU; NVIDIA is renderD128).
Reproduction steps
- On a hybrid AMD+NVIDIA laptop with the display on AMD, open Chromium
(or the Discord webapp) with the default Omarchy session env.
2. Play any H.264 MP4 (or VP9) via a <video> element.
3. The video clock advances (readyState 4, currentTime increasing, no
video.error) but the video area renders black/grey.
Diagnostics
- Headed Chromium + local H.264 MP4: pixels black (mean saturation 0.0 vs
~0.99 software-decoded control), reproduced 3/3 runs; VP9 fails identically.
- Failing-run chrome.log: 90× eglCreateImage failed with 0x00003009
(EGL_BAD_MATCH), Failed to create EGLImage, `Unable to initialize binding
from pixmap, OzoneImageBacking::ProduceSkiaGanesh failed to create GL
representation` — hardware-decoded frames cannot be imported while VA-API
resolves to the NVIDIA driver on the AMD render node.
- Unsetting LIBVA_DRIVER_NAME (or =radeonsi) flips playback to green with
no other change; explicit =nvidia reproduces. mpv (vulkan/vaapi) and
Firefox play the same files fine.
- ffmpeg -hwaccel vaapi on the AMD render node with
LIBVA_DRIVER_NAME=nvidia hangs SIGTERM-immune (needed kill -9).
- YouTube note: Big Buck Bunny played in color at 360p and 1080p because
YouTube served AV1 (software-decoded, immune path). VP9 served over plain
HTTP fails identically, so YouTube videos served as VP9/H.264 fail the same
way. No GPU-process or tab crash signature was found anywhere (no crash
dumps, all tabs stayed alive) — the "crash" is the same dead video surface,
not a separate fault.
View raw text
## Symptoms - Clicking a video (MP4) in the Discord app shows a grey screen. - Video also fails in the system default browser (Chromium) and outside the browser (system-wide, not Discord-only). Firefox works. - YouTube in general also seems to crash. **Fix PR:** https://github.com/omacom/omarchy/pull/10589 ## System details - Omarchy 4.0.2, Hyprland 0.56.2, Wayland session. - Hybrid laptop: NVIDIA AD107M [GeForce RTX 4060 Max-Q Mobile] + AMD HawkPoint iGPU. Display (`eDP-2`) driven by the AMD side. - Chromium 151.0.7922.173 (Discord runs as a Chromium `--app` webapp, `omarchy-launch-webapp https://discord.com/channels/@me`, no extra flags), Firefox 154.0, ffmpeg 9.0.1, mesa 26.2.1, nvidia 610.57.04, `libva-nvidia-driver` 0.0.17. - Session env (set by Omarchy, not user config): `LIBVA_DRIVER_NAME=nvidia`, `__GLX_VENDOR_LIBRARY_NAME=nvidia`, `NVD_BACKEND=direct` (from `default/hypr/nvidia.lua`, GSP branch). - Chromium GPU process runs with `--render-node-override=/dev/dri/renderD129` (AMD iGPU; NVIDIA is renderD128). ## Reproduction steps 1. On a hybrid AMD+NVIDIA laptop with the display on AMD, open Chromium (or the Discord webapp) with the default Omarchy session env. 2. Play any H.264 MP4 (or VP9) via a `<video>` element. 3. The video clock advances (`readyState` 4, `currentTime` increasing, no `video.error`) but the video area renders black/grey. ## Diagnostics - Headed Chromium + local H.264 MP4: pixels black (mean saturation 0.0 vs ~0.99 software-decoded control), reproduced 3/3 runs; VP9 fails identically. - Failing-run `chrome.log`: 90× `eglCreateImage failed with 0x00003009` (EGL_BAD_MATCH), `Failed to create EGLImage`, `Unable to initialize binding from pixmap`, `OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation` — hardware-decoded frames cannot be imported while VA-API resolves to the NVIDIA driver on the AMD render node. - Unsetting `LIBVA_DRIVER_NAME` (or `=radeonsi`) flips playback to green with no other change; explicit `=nvidia` reproduces. mpv (vulkan/vaapi) and Firefox play the same files fine. - `ffmpeg -hwaccel vaapi` on the AMD render node with `LIBVA_DRIVER_NAME=nvidia` hangs SIGTERM-immune (needed `kill -9`). - YouTube note: Big Buck Bunny played in color at 360p and 1080p because YouTube served AV1 (software-decoded, immune path). VP9 served over plain HTTP fails identically, so YouTube videos served as VP9/H.264 fail the same way. No GPU-process or tab crash signature was found anywhere (no crash dumps, all tabs stayed alive) — the "crash" is the same dead video surface, not a separate fault.
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.