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.
USB-C / Thunderbolt power blip reports lid-close while lid is open and instantly suspends
Reported by bjcatar · filed Sep 7, 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
- Machine: Dell XPS 14 DA14260 (laptop chassis, ACPI lid)
- CPU/GPU: Intel Core Ultra X7 358H, Panther Lake Arc B390 (
xe) - Omarchy: 4.0.2-1 (Quattro)
- Hyprland: 0.56.2
- Kernel: 7.1.8-arch1-2-ptl
- BIOS: Dell 1.8.2
What happened
Lid physically open the whole time. Watching YouTube on the laptop panel (no external connected). Recent pointer activity. Screen went fully black. Unplugging the normal USB-C charger brought the session back.
Journal at that moment:
18:25:40 systemd-logind: Lid closed.
18:25:40 systemd-logind: Suspending...
18:25:40 omarchy-shell: lock-requested
18:25:41 PM: suspend entry (s2idle)
18:25:56 systemd-logind: Lid opened.
18:25:56 PM: suspend exitNo omarchy idle cycle fired. Hyprland did not disable eDP. This is not the 5-minute idle lock.
The firmware sent a false `SW_LID` close (USB-C PD / charger tug is a known Dell XPS trigger). Omarchy then did two things with no debounce:
- Hyprland bind
switch:on:Lid Switch→omarchy-system-lid-close(lock) - logind default
HandleLidSwitch=suspend(Omarchy drop-ins only setHandlePowerKey=ignoreandInhibitDelayMaxSec=15)
So a 16-second fake close puts the machine to sleep. Unplugging the charger bounced the sensor to open and woke it — which is why unplugging “fixed” it.
What was expected
Lid-open use, including plugging/unplugging a USB-C charger or Thunderbolt cable for power only, must not suspend. A lid event should be confirmed before lock/sleep.
Why this is an Omarchy bug (not only Dell firmware)
Firmware can lie; the desktop has to debounce it. Stock Omarchy treats the first lid-close as gospel.
This is not a duplicate of #9753. There, ACPI _LID was stuck closed while logind was correct (LidClosed=false). The proposed fix (prefer logind) would not have helped here: logind logged Lid closed too. Both ACPI and logind saw the fake evdev switch.
Related but different: #8758 (lid-close before dock HPD), #10170 (lid-open does not DPMS-enable), #9922 (same XPS 14, real lid-close while docked).
Steps to reproduce
- XPS 14 (or similar Dell USB-C laptop) on Omarchy 4, lid open, on USB-C charger, no external display required.
- Use the machine (video playback is enough).
- Unplug / reseat the USB-C charger, or wait for a PD renegotiation.
- Observe
journalctl -b | grep -i lidreporting close+suspend while the lid never moved.
Suggested Omarchy-side fix
- Inhibit logind
handle-lid-switchin the session (or shipHandleLidSwitch=ignoreand own lid policy). - Debounce: only lock/clamshell if lid state stays closed for a few seconds.
- Ignore lid-close that coincides with
power_supply/ UCSI / Thunderbolt authorize events. - Ignore lid-close while media is playing (optional; this incident was YouTube).
- Keep real lid-close: lock after confirm; suspend only after a longer confirmed close with no external (clamshell already covers docked).
A local workaround that stops the instant suspend: systemd-inhibit --what=handle-lid-switch --mode=block plus unbinding switch:on:Lid Switch / switch:off, with a small watcher that calls omarchy-system-lid-close only after a stable closed state.
View raw text
### System details - **Machine:** Dell XPS 14 DA14260 (laptop chassis, ACPI lid) - **CPU/GPU:** Intel Core Ultra X7 358H, Panther Lake Arc B390 (`xe`) - **Omarchy:** 4.0.2-1 (Quattro) - **Hyprland:** 0.56.2 - **Kernel:** 7.1.8-arch1-2-ptl - **BIOS:** Dell 1.8.2 ### What happened Lid physically **open** the whole time. Watching YouTube on the laptop panel (no external connected). Recent pointer activity. Screen went fully black. Unplugging the normal USB-C charger brought the session back. Journal at that moment: ``` 18:25:40 systemd-logind: Lid closed. 18:25:40 systemd-logind: Suspending... 18:25:40 omarchy-shell: lock-requested 18:25:41 PM: suspend entry (s2idle) 18:25:56 systemd-logind: Lid opened. 18:25:56 PM: suspend exit ``` No `omarchy idle` cycle fired. Hyprland did not disable eDP. This is not the 5-minute idle lock. The firmware sent a **false `SW_LID` close** (USB-C PD / charger tug is a known Dell XPS trigger). Omarchy then did two things with no debounce: 1. Hyprland bind `switch:on:Lid Switch` → `omarchy-system-lid-close` (lock) 2. logind default `HandleLidSwitch=suspend` (Omarchy drop-ins only set `HandlePowerKey=ignore` and `InhibitDelayMaxSec=15`) So a 16-second fake close puts the machine to sleep. Unplugging the charger bounced the sensor to open and woke it — which is why unplugging “fixed” it. ### What was expected Lid-open use, including plugging/unplugging a USB-C charger or Thunderbolt cable for **power only**, must not suspend. A lid event should be confirmed before lock/sleep. ### Why this is an Omarchy bug (not only Dell firmware) Firmware can lie; the desktop has to debounce it. Stock Omarchy treats the first lid-close as gospel. This is **not** a duplicate of #9753. There, ACPI `_LID` was stuck `closed` while **logind was correct** (`LidClosed=false`). The proposed fix (prefer logind) would **not** have helped here: logind logged `Lid closed` too. Both ACPI and logind saw the fake evdev switch. Related but different: #8758 (lid-close before dock HPD), #10170 (lid-open does not DPMS-enable), #9922 (same XPS 14, real lid-close while docked). ### Steps to reproduce 1. XPS 14 (or similar Dell USB-C laptop) on Omarchy 4, lid open, on USB-C charger, no external display required. 2. Use the machine (video playback is enough). 3. Unplug / reseat the USB-C charger, or wait for a PD renegotiation. 4. Observe `journalctl -b | grep -i lid` reporting close+suspend while the lid never moved. ### Suggested Omarchy-side fix - Inhibit logind `handle-lid-switch` in the session (or ship `HandleLidSwitch=ignore` and own lid policy). - Debounce: only lock/clamshell if lid state stays closed for a few seconds. - Ignore lid-close that coincides with `power_supply` / UCSI / Thunderbolt authorize events. - Ignore lid-close while media is playing (optional; this incident was YouTube). - Keep real lid-close: lock after confirm; suspend only after a longer confirmed close with no external (clamshell already covers docked). A local workaround that stops the instant suspend: `systemd-inhibit --what=handle-lid-switch --mode=block` plus unbinding `switch:on:Lid Switch` / `switch:off`, with a small watcher that calls `omarchy-system-lid-close` only after a stable closed state.
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 02:29 UTC