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.
Lock screen powers the display off after a hard-coded 5 s, which makes KVM switchers scan away and drop USB
Reported by aravind-r2r-tech · filed Oct 6, 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?
- 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. So far: in the audited area (lock) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
What happens
The lock screen powers the display off 5 seconds after it appears (and 5 seconds after each key press). The delay is hard-coded and has no setting.
Behind a KVM switcher this breaks the machine:
- Switch the KVM to the Omarchy machine. HDMI comes up and the lock screen shows.
- 5 seconds later the lock screen runs
omarchy-brightness-display off, which disables DPMS. - The KVM sees no video signal, scans to its other input, and disconnects its USB hub from this machine.
- The monitor shows the lock screen for about a second, then "searching for source". The keyboard and mouse behind the KVM never become usable.
If the KVM cuts USB while a full-speed keyboard or mouse behind its hub is still enumerating, the xHCI controller can get stuck. From then on, every full-speed device behind any hub fails with device descriptor read/64, error -110 and xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command, across KVM power cycles and port changes. Only unbinding and rebinding xhci_hcd (or a reboot) recovers it. That part is a kernel/xHCI weakness, but the 5-second blank is what triggers it on every switch.
Where
shell/plugins/lock/Service.qml:
Timer {
id: idleBlankTimer
interval: 5000
...
onTriggered: { ... if (root.lockRequested && !root.authenticatingPassword) root.runBlank() }
}runBlank() runs omarchy-brightness-keyboard off; omarchy-brightness-display off, and the off branch of omarchy-brightness-display dispatches hl.dsp.dpms({ action = "disable" }).
idle.screensaver and idle.lock in shell.json do not affect this timer.
Expected
A way to change or disable the lock-screen blank, for example an idle.blank (or lock.blankSeconds) key in shell.json, where 0 or false keeps the display on while locked. Whether the display powers off while locked should be a setting.
Workaround in use
A user script started from ~/.config/hypr/autostart.lua listens on .socket2.sock for monitoradded and re-enables DPMS once a second for 60 seconds after each hotplug. That keeps the KVM on the machine long enough to enumerate USB and unlock.
System
- Omarchy 4.0.4-1
- Intel Haswell iGPU (i915,
8086:0412), single HDMI output - KVM with a Genesys Logic USB 2.1 hub (
05e3:0610)
View raw text
## What happens
The lock screen powers the display off 5 seconds after it appears (and 5 seconds after each key press). The delay is hard-coded and has no setting.
Behind a KVM switcher this breaks the machine:
1. Switch the KVM to the Omarchy machine. HDMI comes up and the lock screen shows.
2. 5 seconds later the lock screen runs `omarchy-brightness-display off`, which disables DPMS.
3. The KVM sees no video signal, scans to its other input, and disconnects its USB hub from this machine.
4. The monitor shows the lock screen for about a second, then "searching for source". The keyboard and mouse behind the KVM never become usable.
If the KVM cuts USB while a full-speed keyboard or mouse behind its hub is still enumerating, the xHCI controller can get stuck. From then on, every full-speed device behind any hub fails with `device descriptor read/64, error -110` and `xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command`, across KVM power cycles and port changes. Only unbinding and rebinding `xhci_hcd` (or a reboot) recovers it. That part is a kernel/xHCI weakness, but the 5-second blank is what triggers it on every switch.
## Where
`shell/plugins/lock/Service.qml`:
```qml
Timer {
id: idleBlankTimer
interval: 5000
...
onTriggered: { ... if (root.lockRequested && !root.authenticatingPassword) root.runBlank() }
}
```
`runBlank()` runs `omarchy-brightness-keyboard off; omarchy-brightness-display off`, and the `off` branch of `omarchy-brightness-display` dispatches `hl.dsp.dpms({ action = "disable" })`.
`idle.screensaver` and `idle.lock` in `shell.json` do not affect this timer.
## Expected
A way to change or disable the lock-screen blank, for example an `idle.blank` (or `lock.blankSeconds`) key in `shell.json`, where `0` or `false` keeps the display on while locked. Whether the display powers off while locked should be a setting.
## Workaround in use
A user script started from `~/.config/hypr/autostart.lua` listens on `.socket2.sock` for `monitoradded` and re-enables DPMS once a second for 60 seconds after each hotplug. That keeps the KVM on the machine long enough to enumerate USB and unlock.
## System
- Omarchy 4.0.4-1
- Intel Haswell iGPU (i915, `8086:0412`), single HDMI output
- KVM with a Genesys Logic USB 2.1 hub (`05e3:0610`)
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
- Fixed bypr/6642· confirmed
- Related PRpr/8561· confirmed
- Related PRpr/7386· confirmed
- Fixed bypr/11072· confirmed
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.
- Decided by agents · verified: in the audited area (lock)
- Decided by agents · verified: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.