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-5199GitHub issuePublicDecided· Out of scope

recover_modeless() stops at "has a mode" while GTK clients still see the output at 0x0, so Nautilus segfaults after a KVM switch

Reported by a1lazydog · filed Oct 7, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 2 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

recover_modeless() stops at "has a mode" while GTK clients still see the output at 0x0, so Nautilus segfaults after a KVM switchrevision 1 · captured 2026-10-07 09:01 UTC via poll

System details

Intel i5-4690K, NVIDIA RTX 3060 (nvidia-open 610.57.04), Omarchy 4.0.4-1, Hyprland 0.56.2-2, aquamarine 0.15.0-2, gtk4 4.22.4, nautilus 50.3.1, kernel 7.2.5-3-omarchy. Two DP monitors (DP-1 2560x1440@144, DP-3 1920x1080@60) through a UGREEN DP KVM without EDID emulation.

What's wrong?

When switching back from the KVM, Hyprland sometimes re-adds an output at 0x0 (wl_output.mode(1, 0, 0, …), zxdg_output_v1.logical_size(0, 0)), then applies the real mode about 0.5 s later. It sends the new wl_output.mode but not a new `zxdg_output_v1.logical_size`. GTK4 clients that were already running keep that monitor at 0x0, GdkMonitor scale inf, scale factor INT_MIN, until the next output change. Nautilus then segfaults on its next icon redraw on that monitor (nautilus_icon_info_get_paintable, called with scale=-2147483648 after gtk_icon_theme_lookup_by_gicon: assertion 'scale > 0' failed). This happened 3 times (Sept 18, Oct 1, Oct 6). voxtype-osd logs gdk_monitor_set_scale: assertion 'scale > 0.' failed on the same returns.

In about 2 of 5 returns the output is first announced at 0x0; the others arrive already sized and are fine. A Wayland protocol trace (WAYLAND_DEBUG=client on a GTK4 client watching GdkMonitor notify) showed DP-1 stuck at scale=inf for 54 s, until a manual hyprctl reload. The reload re-sent logical_size(2560, 1440) and the GdkMonitor went straight back to scale 1. In Hyprland's XDGOutput.cpp, updateAllOutputs() runs only on monitor.layoutChanged and config.reloaded, which explains why reload is the fix. The root cause is Hyprland's to fix, but Omarchy's recovery path is where it can be handled today.

The Omarchy gap: recover_modeless() in omarchy-hyprland-monitor-watch reloads only while omarchy-hyprland-monitor-modeless reports 0x0, and stops as soon as hyprctl shows a mode. A reload issued while the output is still 0x0 re-sends 0x0. Once the mode arrives no reload follows, so clients keep the stale size. (I did not confirm whether recover_modeless() caught the 0x0 window on these returns. Either way, no reload happened after the mode arrived.)

Suggested fix: after a monitor is re-added, once every enabled output reports a non-zero mode (and FALLBACK is gone), issue one more hyprctl reload. Or: in recover_modeless(), reload once more when the state goes from modeless to recovered.

Workaround in use here: a user service listening on socket2 monitoraddedv2. It waits until all real outputs have a non-zero mode and FALLBACK is gone, holds for 0.75 s, then runs hyprctl reload once, respecting omarchy-hyprland-reload-guard. Verified over 4 KVM round trips: the bad return was re-synced in about 1.9 s instead of staying stale, and no crashes since.

Related but different: #12481 and #13073 (outputs that stay dark at 0x0, where reload can't recover them). Here the monitor recovers on screen and only the clients' xdg-output size is stale. #13904 shows the same GTK assertion after a dock resume.

Filed by Claude Opus 5.5 via Claude Code.

View raw text
### System details

Intel i5-4690K, NVIDIA RTX 3060 (nvidia-open 610.57.04), Omarchy 4.0.4-1, Hyprland 0.56.2-2, aquamarine 0.15.0-2, gtk4 4.22.4, nautilus 50.3.1, kernel 7.2.5-3-omarchy. Two DP monitors (DP-1 2560x1440@144, DP-3 1920x1080@60) through a UGREEN DP KVM without EDID emulation.

### What's wrong?

When switching back from the KVM, Hyprland sometimes re-adds an output at 0x0 (`wl_output.mode(1, 0, 0, …)`, `zxdg_output_v1.logical_size(0, 0)`), then applies the real mode about 0.5 s later. It sends the new `wl_output.mode` but **not a new `zxdg_output_v1.logical_size`**. GTK4 clients that were already running keep that monitor at 0x0, `GdkMonitor` scale `inf`, scale factor `INT_MIN`, until the next output change. Nautilus then segfaults on its next icon redraw on that monitor (`nautilus_icon_info_get_paintable`, called with `scale=-2147483648` after `gtk_icon_theme_lookup_by_gicon: assertion 'scale > 0' failed`). This happened 3 times (Sept 18, Oct 1, Oct 6). voxtype-osd logs `gdk_monitor_set_scale: assertion 'scale > 0.' failed` on the same returns.

In about 2 of 5 returns the output is first announced at 0x0; the others arrive already sized and are fine. A Wayland protocol trace (`WAYLAND_DEBUG=client` on a GTK4 client watching `GdkMonitor` notify) showed DP-1 stuck at `scale=inf` for 54 s, until a manual `hyprctl reload`. The reload re-sent `logical_size(2560, 1440)` and the GdkMonitor went straight back to scale 1. In Hyprland's `XDGOutput.cpp`, `updateAllOutputs()` runs only on `monitor.layoutChanged` and `config.reloaded`, which explains why reload is the fix. The root cause is Hyprland's to fix, but Omarchy's recovery path is where it can be handled today.

**The Omarchy gap:** `recover_modeless()` in `omarchy-hyprland-monitor-watch` reloads only while `omarchy-hyprland-monitor-modeless` reports 0x0, and stops as soon as `hyprctl` shows a mode. A reload issued while the output is still 0x0 re-sends 0x0. Once the mode arrives no reload follows, so clients keep the stale size. (I did not confirm whether `recover_modeless()` caught the 0x0 window on these returns. Either way, no reload happened after the mode arrived.)

**Suggested fix:** after a monitor is re-added, once every enabled output reports a non-zero mode (and FALLBACK is gone), issue one more `hyprctl reload`. Or: in `recover_modeless()`, reload once more when the state goes from modeless to recovered.

**Workaround in use here:** a user service listening on socket2 `monitoraddedv2`. It waits until all real outputs have a non-zero mode and FALLBACK is gone, holds for 0.75 s, then runs `hyprctl reload` once, respecting `omarchy-hyprland-reload-guard`. Verified over 4 KVM round trips: the bad return was re-synced in about 1.9 s instead of staying stale, and no crashes since.

Related but different: #12481 and #13073 (outputs that stay dark at 0x0, where reload can't recover them). Here the monitor recovers on screen and only the clients' xdg-output size is stale. #13904 shows the same GTK assertion after a dock resume.

Filed by Claude Opus 5.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 22:07 UTC