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.
External monitors on a USB-C dock never return after undocking (aquamarine 0.15.0 regression)
Reported by jacobrosenthal · filed Sep 9, 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
System details
XPS 9320, IBM dock, 2 lg monitors, omarchy 4.0.3-1
What's wrong?
From claude:
What happens
On a laptop docked via USB-C with external displays on DisplayPort MST, unplugging
the dock kills the external displays permanently. Replugging does nothing. Only a
reboot brings them back.
Booting with the dock attached works fine, and hot-plugging from a clean boot works
fine. Only undocking is broken.
Cause
Not Omarchy, and not the kernel — it is aquamarine 0.15.0, which Omarchy currently
ships. Upstream: https://github.com/hyprwm/aquamarine/issues/386
0.15.0 added a guard in commitState rejecting commits to disconnected outputs, butdisconnect() marks the connector disconnected before the compositor commitssetEnabled(false). The disable is rejected, so the kernel's CRTC stays active. That
orphaned pipe holds intel_tc's link_refcount, the Type-C port can never
re-evaluate its mode, and every later modeset fails.
Introduced by aquamarine commit 9d6fed9 ("core/drm: introduce async commits").
Fix: https://github.com/hyprwm/aquamarine/pull/395 (open, unmerged).
Why this is easy to misdiagnose
On Arch this arrived in the same pacman transaction as linux 7.1.9 -> 7.2.3, mesa, and
hyprland. It presents as a kernel/i915 bug — monitors enumerate at 0x0@60, every DRM
atomic modeset fails EINVAL at every resolution. Downgrading the kernel does not help.
There is also a red herring nearby: typec_altmode_update_active /module_put WARNs
and a typec_displayport refcount of -1. Those are real but pre-existing and unrelated.
(Do not modprobe -r typec_displayport at refcount -1 — it hits a BUG_ON while holdingmodule_mutex and hangs every /proc/modules reader.)
Repro
- Boot docked, external displays on DP MST behind a USB-C dock (Intel i915).
- Unplug the dock.
- Replug. External displays never return; a reboot is required.
Check for the orphaned pipes after step 2 — more CRTCs with a non-zero fb than
displays Hyprland knows about:
modetest -M i915 -p | sed -n '/^CRTCs:/,/^planes:/p' \
| grep -E '^[0-9]+[[:space:]]+[0-9]+[[:space:]]+\(' | awk '$2 != 0'
hyprctl monitors -j | jq length
Verified environment
Dell XPS 9320, Raptor Lake-P, i915, kernel 7.2.3-arch1-3, Hyprland 0.56.2,
aquamarine 0.15.0-2, Omarchy 4.0.3. Lenovo ThinkPad USB-C dock, 2x LG UltraFine 4K.
Fix confirmed
Rebuilding aquamarine 0.15.0 with PR #395 applied resolves it completely — verified by
unplug/replug with no workarounds. Suggest Omarchy either carry the patch until #395
merges, or track the upstream issue for users hitting this after an update.
View raw text
### System details
XPS 9320, IBM dock, 2 lg monitors, omarchy 4.0.3-1
### What's wrong?
From claude:
## What happens
On a laptop docked via USB-C with external displays on DisplayPort MST, unplugging
the dock kills the external displays permanently. Replugging does nothing. Only a
reboot brings them back.
Booting *with* the dock attached works fine, and hot-plugging from a clean boot works
fine. Only undocking is broken.
## Cause
Not Omarchy, and not the kernel — it is `aquamarine` 0.15.0, which Omarchy currently
ships. Upstream: https://github.com/hyprwm/aquamarine/issues/386
0.15.0 added a guard in `commitState` rejecting commits to disconnected outputs, but
`disconnect()` marks the connector disconnected *before* the compositor commits
`setEnabled(false)`. The disable is rejected, so the kernel's CRTC stays active. That
orphaned pipe holds `intel_tc`'s `link_refcount`, the Type-C port can never
re-evaluate its mode, and every later modeset fails.
Introduced by aquamarine commit 9d6fed9 ("core/drm: introduce async commits").
Fix: https://github.com/hyprwm/aquamarine/pull/395 (open, unmerged).
## Why this is easy to misdiagnose
On Arch this arrived in the same pacman transaction as linux 7.1.9 -> 7.2.3, mesa, and
hyprland. It presents as a kernel/i915 bug — monitors enumerate at `0x0@60`, every DRM
atomic modeset fails EINVAL at every resolution. Downgrading the kernel does not help.
There is also a red herring nearby: `typec_altmode_update_active` /`module_put` WARNs
and a `typec_displayport` refcount of -1. Those are real but pre-existing and unrelated.
(Do not `modprobe -r typec_displayport` at refcount -1 — it hits a BUG_ON while holding
`module_mutex` and hangs every `/proc/modules` reader.)
## Repro
1. Boot docked, external displays on DP MST behind a USB-C dock (Intel i915).
2. Unplug the dock.
3. Replug. External displays never return; a reboot is required.
Check for the orphaned pipes after step 2 — more CRTCs with a non-zero fb than
displays Hyprland knows about:
modetest -M i915 -p | sed -n '/^CRTCs:/,/^planes:/p' \
| grep -E '^[0-9]+[[:space:]]+[0-9]+[[:space:]]+\(' | awk '$2 != 0'
hyprctl monitors -j | jq length
## Verified environment
Dell XPS 9320, Raptor Lake-P, i915, kernel 7.2.3-arch1-3, Hyprland 0.56.2,
aquamarine 0.15.0-2, Omarchy 4.0.3. Lenovo ThinkPad USB-C dock, 2x LG UltraFine 4K.
## Fix confirmed
Rebuilding aquamarine 0.15.0 with PR #395 applied resolves it completely — verified by
unplug/replug with no workarounds. Suggest Omarchy either carry the patch until #395
merges, or track the upstream issue for users hitting this after an 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.
- Out of scopeDecided by agents · verified · 2026-10-09 11:21 UTC