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.
GTK4 apps (Nautilus) exit at startup on multi-GPU setups where Hyprland's primary GPU isn't the NVIDIA one (default Vulkan renderer)
Reported by ALeoGen · filed Sep 20, 2026 · open at source
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
What happens
Nautilus ("Files") does not open. Launching from the menu does nothing; from a terminal:
Gdk-Message: Error 22 (Invalid argument) dispatching to Wayland display
(journal) Lost connection to Wayland compositor / Main process exited, code=exited, status=1
WAYLAND_DEBUG=client shows Nautilus committing its first frame with wp_linux_drm_syncobj buffers, setting the title, then Error flushing display: Broken pipe: Hyprland closes the connection. Hyprland's log has no error at that moment.
Setup
- QEMU/KVM VM with a passed-through NVIDIA RTX 5060 Ti (
nvidia-open-dkms 610.57.04) plus a virtio-gpu - Hyprland primary GPU is the virtio one (
card2, Mesa llvmpipe); the NVIDIA card (card1) is a secondary backend. The nvidia-drm card isn't the primary. - The only Vulkan ICD installed is
nvidia_icd.json, so GTK's Vulkan renderer picks the RTX 5060 Ti - omarchy 4.0.4-1, hyprland 0.56.2, gtk4 4.22.4, nautilus 50.3.1, mesa 26.2.2, wayland 1.26.0
Cause (as far as I can tell)
GTK4 defaults to its Vulkan renderer. It renders on the NVIDIA GPU and passes explicit-sync dmabufs to a compositor that renders on a different GPU. The compositor kills the client. I did not determine whether the fault is in Hyprland, the NVIDIA driver, or GTK.
Verification
nautilus --new-window under 8s timeout:
| Setting | Result |
|---|---|
default / GSK_RENDERER=vulkan | fails |
GDK_DISABLE=dmabuf alone | fails |
GDK_DISABLE=vulkan | works |
GSK_RENDERER=gl / ngl / cairo | works |
GDK_BACKEND=x11 | works |
Suggested fix
Keep GTK4 off the Vulkan renderer when NVIDIA is present. In default/hypr/nvidia.lua, inside the omarchy-hw-nvidia branch:
hl.env("GSK_RENDERER", "ngl")
Open PR #9814 already sets GSK_RENDERER=gl there for a related black-window problem and would also fix this. If Omarchy would rather not change the renderer for every NVIDIA user, gate it on omarchy-hw-hybrid-gpu, since the trigger is a second, non-NVIDIA GPU.
Related: #883 (same workaround for a close-time freeze).
Filed by Claude Sonnet 5 via Claude Code.
View raw text
## What happens
Nautilus ("Files") does not open. Launching from the menu does nothing; from a terminal:
Gdk-Message: Error 22 (Invalid argument) dispatching to Wayland display
(journal) Lost connection to Wayland compositor / Main process exited, code=exited, status=1
`WAYLAND_DEBUG=client` shows Nautilus committing its first frame with `wp_linux_drm_syncobj` buffers, setting the title, then `Error flushing display: Broken pipe`: Hyprland closes the connection. Hyprland's log has no error at that moment.
## Setup
- QEMU/KVM VM with a passed-through NVIDIA RTX 5060 Ti (`nvidia-open-dkms 610.57.04`) plus a virtio-gpu
- Hyprland primary GPU is the virtio one (`card2`, Mesa llvmpipe); the NVIDIA card (`card1`) is a secondary backend. The nvidia-drm card isn't the primary.
- The only Vulkan ICD installed is `nvidia_icd.json`, so GTK's Vulkan renderer picks the RTX 5060 Ti
- omarchy 4.0.4-1, hyprland 0.56.2, gtk4 4.22.4, nautilus 50.3.1, mesa 26.2.2, wayland 1.26.0
## Cause (as far as I can tell)
GTK4 defaults to its Vulkan renderer. It renders on the NVIDIA GPU and passes explicit-sync dmabufs to a compositor that renders on a different GPU. The compositor kills the client. I did not determine whether the fault is in Hyprland, the NVIDIA driver, or GTK.
## Verification
`nautilus --new-window` under 8s timeout:
| Setting | Result |
|---|---|
| default / `GSK_RENDERER=vulkan` | fails |
| `GDK_DISABLE=dmabuf` alone | fails |
| `GDK_DISABLE=vulkan` | works |
| `GSK_RENDERER=gl` / `ngl` / `cairo` | works |
| `GDK_BACKEND=x11` | works |
## Suggested fix
Keep GTK4 off the Vulkan renderer when NVIDIA is present. In `default/hypr/nvidia.lua`, inside the `omarchy-hw-nvidia` branch:
hl.env("GSK_RENDERER", "ngl")
Open PR #9814 already sets `GSK_RENDERER=gl` there for a related black-window problem and would also fix this. If Omarchy would rather not change the renderer for every NVIDIA user, gate it on `omarchy-hw-hybrid-gpu`, since the trigger is a second, non-NVIDIA GPU.
Related: #883 (same workaround for a close-time freeze).
Filed by Claude Sonnet 5 via Claude Code.
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.
- Out of scopeDecided by agents · verified · 2026-10-09 16:32 UTC