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 clobbers saved keyboard backlight level: omarchy-brightness-keyboard off re-saves 0, so restore-on-wake brings back 0
Reported by symbolofraisins · filed Aug 31, 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 happens
After unlocking, the keyboard backlight stays off. omarchy-system-wake does callomarchy-brightness-keyboard restore, but it restores 0, because the saved level
has been overwritten by then.
Root cause
omarchy-brightness-keyboard off is brightnessctl -sd "$device" set 0 — it saves the
current level before blanking (bin/omarchy-brightness-keyboard:28-30). That is only
correct the first time. Run while already blanked, it saves 0 over the real level.
The lock screen runs it more than once per lock. shell/plugins/lock/Service.qml:411
invokes it from blankProcess, and idleBlankTimer re-arms whenever password auth is
not in flight (Service.qml:481, also :169 and :424), so runBlank() fires again on
a re-lock, a resume while locked, or an abandoned auth attempt.
Reproduction
Deterministic, no lock screen needed:
$ brightnessctl -d asus::kbd_backlight set 3
$ cat /run/user/1000/brightnessctl/leds/asus::kbd_backlight # -> (previous)
$ omarchy-brightness-keyboard off
$ cat /run/user/1000/brightnessctl/leds/asus::kbd_backlight # -> 3 correct
$ omarchy-brightness-keyboard off
$ cat /run/user/1000/brightnessctl/leds/asus::kbd_backlight # -> 0 clobbered
$ omarchy-brightness-keyboard restore
$ cat /sys/class/leds/asus::kbd_backlight/brightness # -> 0 stays offThrough the UI: set the backlight non-zero, lock, let the blank timer fire, wake the lock
screen and let it blank a second time, then unlock. The backlight does not return.
Expected
The backlight returns to the level it had before locking.
Suggested fix
Make off idempotent so it never saves a blanked value — in bin/omarchy-brightness-keyboard:
if [[ $direction == "off" ]]; then
# Don't re-save 0 over the real level when already blanked; the lock screen
# can call this more than once per lock.
(( $(brightnessctl -d "$device" get) > 0 )) || exit 0
brightnessctl -sd "$device" set 0 >/dev/null
exit 0System
- Omarchy 4.0.1-1 (code above is unchanged on
mainas of filing) - ASUS Zenbook 14 UX3405MA_Q425MA
- Intel Core Ultra 7 155H / Intel Arc Graphics (Meteor Lake-P)
- Kernel 7.1.9-arch1-2
- LED device
asus::kbd_backlight, max_brightness 3
View raw text
## What happens After unlocking, the keyboard backlight stays off. `omarchy-system-wake` does call `omarchy-brightness-keyboard restore`, but it restores `0`, because the saved level has been overwritten by then. ## Root cause `omarchy-brightness-keyboard off` is `brightnessctl -sd "$device" set 0` — it saves the **current** level before blanking (bin/omarchy-brightness-keyboard:28-30). That is only correct the first time. Run while already blanked, it saves `0` over the real level. The lock screen runs it more than once per lock. `shell/plugins/lock/Service.qml:411` invokes it from `blankProcess`, and `idleBlankTimer` re-arms whenever password auth is not in flight (`Service.qml:481`, also `:169` and `:424`), so `runBlank()` fires again on a re-lock, a resume while locked, or an abandoned auth attempt. ## Reproduction Deterministic, no lock screen needed: ```console $ brightnessctl -d asus::kbd_backlight set 3 $ cat /run/user/1000/brightnessctl/leds/asus::kbd_backlight # -> (previous) $ omarchy-brightness-keyboard off $ cat /run/user/1000/brightnessctl/leds/asus::kbd_backlight # -> 3 correct $ omarchy-brightness-keyboard off $ cat /run/user/1000/brightnessctl/leds/asus::kbd_backlight # -> 0 clobbered $ omarchy-brightness-keyboard restore $ cat /sys/class/leds/asus::kbd_backlight/brightness # -> 0 stays off ``` Through the UI: set the backlight non-zero, lock, let the blank timer fire, wake the lock screen and let it blank a second time, then unlock. The backlight does not return. ## Expected The backlight returns to the level it had before locking. ## Suggested fix Make `off` idempotent so it never saves a blanked value — in `bin/omarchy-brightness-keyboard`: ```bash if [[ $direction == "off" ]]; then # Don't re-save 0 over the real level when already blanked; the lock screen # can call this more than once per lock. (( $(brightnessctl -d "$device" get) > 0 )) || exit 0 brightnessctl -sd "$device" set 0 >/dev/null exit 0 ``` ## System - Omarchy 4.0.1-1 (code above is unchanged on `main` as of filing) - ASUS Zenbook 14 UX3405MA_Q425MA - Intel Core Ultra 7 155H / Intel Arc Graphics (Meteor Lake-P) - Kernel 7.1.9-arch1-2 - LED device `asus::kbd_backlight`, max_brightness 3
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
- Fixed bypr/10366· confirmed
- Fixed bypr/12960· 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.