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.
Keyboard backlight stays off after unlock (idle-blank restore doesn't fire reliably)
Reported by Alkiviadroot · filed Aug 24, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #6667 (R-1877). GitHub close reason: completed.
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
What happened
Omarchy's lock screen dims the keyboard backlight to 0 after ~5s of being
locked (Service.qml's idleBlankTimer -> blankProcess -> "omarchy-brightness-keyboard off").
On unlock, finishUnlock() is supposed to restore it via omarchy-system-wake
-> "omarchy-brightness-keyboard restore", but this restore does not
reliably take effect. Display brightness restores fine; only the keyboard
LED gets stuck off.
Steps to reproduce
- Lock the session (manual lock or lid close).
- Wait >5s without touching the keyboard (idle-blank triggers, backlight -> 0).
- Unlock with password.
- Keyboard backlight stays off; requires manual Fn+Space to restore.
Verification
Polled /sys/class/leds/tpacpi::kbd_backlight/brightness every 2-3s across
two independent real lock/unlock cycles, cross-referenced againstomarchy-shell lock status and journalctl "omarchy lock ... unlocked"
events. Backlight dimmed to 0 as expected ~5s into lock, then stayed at 0
well after the shell reported the session unlocked. Confirmed the
underlying brightnessctl save/restore mechanism itself works correctly in
isolation (brightnessctl -sd <device> set 0 then `brightnessctl -rd
<device>` restores correctly), so the bug is specifically in the wake path
in Service.qml not firing/landing reliably on unlock (suspected race
around wakeProcess.running not resetting between invocations).
Expected
Keyboard backlight should return to its prior brightness immediately on
unlock, same as the display does.
System
- Omarchy: 4.0.0-1
- Hyprland: 0.56.2
- Kernel: 7.1.8-arch1-3
- Machine: Lenovo ThinkPad T14 Gen 1 (20S1S64W1A)
- CPU: Intel Core i5-10310U
- GPU: Intel UHD Graphics (CometLake-U GT2)
View raw text
### What happened Omarchy's lock screen dims the keyboard backlight to 0 after ~5s of being locked (Service.qml's idleBlankTimer -> blankProcess -> "omarchy-brightness-keyboard off"). On unlock, finishUnlock() is supposed to restore it via omarchy-system-wake -> "omarchy-brightness-keyboard restore", but this restore does not reliably take effect. Display brightness restores fine; only the keyboard LED gets stuck off. ### Steps to reproduce 1. Lock the session (manual lock or lid close). 2. Wait >5s without touching the keyboard (idle-blank triggers, backlight -> 0). 3. Unlock with password. 4. Keyboard backlight stays off; requires manual Fn+Space to restore. ### Verification Polled /sys/class/leds/tpacpi::kbd_backlight/brightness every 2-3s across two independent real lock/unlock cycles, cross-referenced against `omarchy-shell lock status` and journalctl "omarchy lock ... unlocked" events. Backlight dimmed to 0 as expected ~5s into lock, then stayed at 0 well after the shell reported the session unlocked. Confirmed the underlying brightnessctl save/restore mechanism itself works correctly in isolation (`brightnessctl -sd <device> set 0` then `brightnessctl -rd <device>` restores correctly), so the bug is specifically in the wake path in Service.qml not firing/landing reliably on unlock (suspected race around wakeProcess.running not resetting between invocations). ### Expected Keyboard backlight should return to its prior brightness immediately on unlock, same as the display does. ### System - Omarchy: 4.0.0-1 - Hyprland: 0.56.2 - Kernel: 7.1.8-arch1-3 - Machine: Lenovo ThinkPad T14 Gen 1 (20S1S64W1A) - CPU: Intel Core i5-10310U - GPU: Intel UHD Graphics (CometLake-U GT2)
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/8119· confirmed
- Related PRpr/10366· 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.
No decision has been recorded yet.