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.
Turning off DPMS causes Hyprlock to crash, requiring hard reboot of Omarchy
Reported by nkasco · filed Aug 26, 2025Closed upstream on 2025-10-09 by ryanrhughes, as a duplicate of #26 (R-2251). GitHub close reason: duplicate.
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?
- Not yet mapped to any requirement or component.
- 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. No decision has been recorded yet.
Original report
Whenever my machine goes idle and the lockscreen displays, hypridle.conf has a configuration listener to turn off dpms.
This puts the screen to sleep, and for my LG ultrawide monitor when the light goes from white to amber when it doesn't detect input, this seems to be consistently crashing hyprlock each time.
Repro Instructions: Simulating the commands in omarchy-lock-screen allows me to repro this at will.
(Really what seems to be doing it is the hyprctl dispatch dpms off and having the monitor off for long enough that it doesn't detect input, if I do this with shorter intervals the issues doesn't repro since the monitor hasn't lost input detection)
**Workaround:** Comment out the listener in ~/.config/hypr/hypridle.conf that runs hyprctl dispatch dpms off#listener {
timeout = 330 # 5.5min
on-timeout = hyprctl dispatch dpms off # screen off when timeout has passed
on-resume = hyprctl dispatch dpms on && brightnessctl -r # screen on when activity is detected
#}
While this will lead to the screen locking but next turning off the monitor, it's better than crashing.
**Proposed Omarchy Workaround:** Provide a setting in Omarchy to allow the user to choose if their screen should turn off or not when idle. This is really a hyprlock issue, but since it's provided by Omarchy we should improve the UX.View raw text
Whenever my machine goes idle and the lockscreen displays, hypridle.conf has a configuration listener to turn off dpms.
This puts the screen to sleep, and for my LG ultrawide monitor when the light goes from white to amber when it doesn't detect input, this seems to be consistently crashing hyprlock each time.
**Repro Instructions:** Simulating the commands in omarchy-lock-screen allows me to repro this at will.
```loginctl lock-session;sleep 3;hyprctl dispatch dpms off;sleep 10;hyprctl dispatch dpms on && brightnessctl -r```
(Really what seems to be doing it is the hyprctl dispatch dpms off and having the monitor off for long enough that it doesn't detect input, if I do this with shorter intervals the issues doesn't repro since the monitor hasn't lost input detection)
**Workaround:** Comment out the listener in ~/.config/hypr/hypridle.conf that runs hyprctl dispatch dpms off
```
#listener {
# timeout = 330 # 5.5min
# on-timeout = hyprctl dispatch dpms off # screen off when timeout has passed
# on-resume = hyprctl dispatch dpms on && brightnessctl -r # screen on when activity is detected
#}
```
While this will lead to the screen locking but next turning off the monitor, it's better than crashing.
**Proposed Omarchy Workaround:** Provide a setting in Omarchy to allow the user to choose if their screen should turn off or not when idle. This is really a hyprlock issue, but since it's provided by Omarchy we should improve the UX.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.
No decision has been recorded yet.