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 restore fails after lock (brightnessctl saves 0 after Dell stop_timeout)
Reported by sotoreynah · filed Aug 9, 2026 · open at source
At a glance
- 1 · What is claimed?
- ConfirmedReproducible: A second keyboard off while the LED is already 0 overwrites the saved non-zero backlight level, so restore leaves the backlight at 0.
- Not confirmedAffects the lock component
- 3 · Is it reproducible?
- An engine-executed run exited 1 and showed the defect signal. See reproducer
- 4 · What remains unclear?
- Affects the lock component — no requirement of the lock component is confirmed as violated
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Draft spec
When the lock blanks the keyboard backlight, the system shall save a brightness level only when that level is greater than zero. After unlock, restoring the keyboard backlight shall apply the last saved non-zero level rather than a zero that was current only because the light was already off.
Why this is an open question
Draft for a human. Keyboard off today saves the current brightness even when it is already 0, so a later restore leaves the backlight dark. No approved requirement states this behaviour.
Proposed on this report's branch @ 89efb8e076 · specs/software/requirements/SW-REQ-261009-GW3G.req.yaml · not part of the audited spec until approved and merged
Written after the validation was sealed at ec0df1ae98: the seal covers the reproducer and the observed behaviour, not this proposed text.
Original report
Omarchy version
3.8.4
Hardware
Dell laptop with dell::kbd_backlight (max brightness 2)
Summary
After idle lock/unlock, the keyboard backlight stays off until the physical backlight key is pressed. Software restore does not bring it back, and typing does not re-enable it either.
Expected
omarchy-system-wake restores the previous non-zero keyboard backlight level.
Actual
Backlight stays at 0 after unlock. Only the hardware backlight key restores it.
Root cause
Dell exposes an idle timeout via sysfs:
/sys/class/leds/dell::kbd_backlight/stop_timeout(default1m)- After ~1 minute idle, brightness is already
0
Lock path in omarchy-system-lock (when not OMARCHY_LOCK_ONLY) does:
omarchy-brightness-keyboard off # brightnessctl -s set 0omarchy-brightness-keyboard off is effectively:
brightnessctl -sd "$device" set 0That saves the current value, then sets 0. By lock time (~2.5 min via hypridle), current is already 0 from stop_timeout, so the saved state is 0.
Wake then runs:
omarchy-brightness-keyboard restore # brightnessctl -rwhich restores 0. Explicit software set 0 also tends to leave Dell in a full “off” mode where activity / start_triggers no longer revive the light until the physical key is used.
Repro
- Set keyboard backlight to a non-zero level
- Idle until hypridle locks (or lock via system lock)
- Unlock
- Keyboard backlight remains off
Confirmed on system
- Save file can contain
0:/run/user/$UID/brightnessctl/leds/dell::kbd_backlight stop_timeout=1m,start_triggers=+keyboard +touchpad- Related scripts:
omarchy-brightness-keyboard,omarchy-system-lock,omarchy-system-wake
Suggested fix
In omarchy-brightness-keyboard (and/or lock/wake):
- Persist last non-zero level in a state file
- On
off: save only if current > 0; never overwrite state with 0 - On
restore: apply last non-zero level (fallback to a sane default, e.g. mid step) - Optionally snapshot level on idle before
stop_timeout(e.g. ~30s)
Happy to test a PR on Dell hardware.
View raw text
### Omarchy version 3.8.4 ### Hardware Dell laptop with `dell::kbd_backlight` (max brightness 2) ### Summary After idle lock/unlock, the keyboard backlight stays off until the physical backlight key is pressed. Software restore does not bring it back, and typing does not re-enable it either. ### Expected `omarchy-system-wake` restores the previous non-zero keyboard backlight level. ### Actual Backlight stays at 0 after unlock. Only the hardware backlight key restores it. ### Root cause Dell exposes an idle timeout via sysfs: - `/sys/class/leds/dell::kbd_backlight/stop_timeout` (default `1m`) - After ~1 minute idle, brightness is already `0` Lock path in `omarchy-system-lock` (when not `OMARCHY_LOCK_ONLY`) does: ```bash omarchy-brightness-keyboard off # brightnessctl -s set 0 ``` `omarchy-brightness-keyboard off` is effectively: ```bash brightnessctl -sd "$device" set 0 ``` That **saves the current value, then sets 0**. By lock time (~2.5 min via hypridle), current is already **0** from `stop_timeout`, so the saved state is **0**. Wake then runs: ```bash omarchy-brightness-keyboard restore # brightnessctl -r ``` which restores **0**. Explicit software `set 0` also tends to leave Dell in a full “off” mode where activity / `start_triggers` no longer revive the light until the physical key is used. ### Repro 1. Set keyboard backlight to a non-zero level 2. Idle until hypridle locks (or lock via system lock) 3. Unlock 4. Keyboard backlight remains off ### Confirmed on system - Save file can contain `0`: `/run/user/$UID/brightnessctl/leds/dell::kbd_backlight` - `stop_timeout=1m`, `start_triggers=+keyboard +touchpad` - Related scripts: `omarchy-brightness-keyboard`, `omarchy-system-lock`, `omarchy-system-wake` ### Suggested fix In `omarchy-brightness-keyboard` (and/or lock/wake): 1. Persist **last non-zero** level in a state file 2. On `off`: save only if current > 0; never overwrite state with 0 3. On `restore`: apply last non-zero level (fallback to a sane default, e.g. mid step) 4. Optionally snapshot level on idle *before* `stop_timeout` (e.g. ~30s) Happy to test a PR on Dell hardware.
Also reported as
R-1877 is the earliest report of this defect, filed Aug 9, 2026. 2 later reports describe the same defect.
- Aug 9, 2026R-1877 · this report— the original
- ·Decided by agents · verified
Open upstream.
- ·Decided by agents · verified
Open upstream.
Validation
AI validator grok-promoter-1 (grok-4.7) · evaluated revision 1 at product commit ecae57a237ef · sealed 2026-10-09T18:57:15Z
After a keyboard off saves a non-zero backlight level and sets the LED to 0, a second off (the lock blank path can run off again before wake) saves that current 0. Restore, which omarchy-system-wake runs, then applies 0 instead of the earlier level. No requirement states that keyboard-off must keep a previously saved non-zero level when the LED is already 0: SW-REQ-260912-ND55 covers display blank timing and the suspend re-arm only. KI-LOCK-SCREENS-CHANGE-BLANK-LOST is a different defect (hotplug leaves displays awake because the blank timer is not re-armed). Spec gap, not a duplicate.
- ConfirmedReproducible
Reproducible: A second keyboard off while the LED is already 0 overwrites the saved non-zero backlight level, so restore leaves the backlight at 0.
Engine: engine-executed run exited 1 and showed the defect signal
Evidence: file pocs/reproducers/ki-261009-4mb1/repro.sh
Validator's rationale (commentary): The lock blank command is `omarchy-brightness-keyboard off` (shell/plugins/lock/Service.qml blankProcess) and wake runs `omarchy-brightness-keyboard restore` (bin/omarchy-system-wake). off is `brightnessctl -s set 0`, which saves the current value even when it is already 0. The reproducer drives those two commands against a fake kbd_backlight with real brightnessctl: the first off saves 80, the second off saves 0, and restore applies 0. Correct behaviour is that restore returns 80.
Affects the lock component
Engine: no requirement of the lock component is confirmed as violated
Validator's rationale (commentary): The repeated off is started by the lock plugin's blank path; wake in the same lock lifecycle applies the saved value. The brightness helper is the mechanism, and the audited caller is lock.
Engine reference checks at ec0df1ae98fe (8/8 ok)
- okcommitec0df1ae98fe73ea2ee96da991c321346d8f9d4a
- okbase commitecae57a237ef4b084c234a25835b8145ddc5295d
- okbase ancestryecae57a237ef4b084c234a25835b8145ddc5295d
- okproduct code untouchedthis report's reproducer branch
- okbranchthis report's reproducer branch
- okfilepocs/reproducers/ki-261009-4mb1/repro.sh
- okcomponentlock
- okknown issueKI-LOCK-SCREENS-CHANGE-BLANK-LOST
The engine's own check, at validation time, that the commits, the reproducer branch (touching only reproducer files), the reproducer files and every mapped requirement / component / known issue really exist.
Validator-authored hypothesis. Each claim's verification is engine-computed: confirmed only from an engine-executed reproducer run recorded in this record, refuted when recorded evidence contradicts it. Prose is commentary. The disposition of the report is a human decision.
Reproducer
bash pocs/reproducers/ki-261009-4mb1/repro.sh
Setup failure: exit 2 means the reproducer could not set up (e.g. the product did not build) — such a run decides nothing.
Defect signal: output contains PROOF-REPRODUCER: defect-present KI-261009-4MB1
PROOF-REPRODUCER: defect-present KI-261009-4MB1
after-first-off current=0 saved=80 after-second-off saved=0 after-restore brightness=0 expected=80 PROOF-REPRODUCER: defect-present KI-261009-4MB1
Needs: linux · linux-session · toolchain · ran on linux/amd64 · Real brightnessctl against a fake kbd_backlight LED in a user mount namespace. No physical keyboard backlight.
Linked
- Related PRpr/8119· confirmed
- Related PRpr/10366· confirmed
- Related PRpr/12960· confirmed
- Known issueLock keyboard-off saves brightness 0 when the light is already off, so unlock restores darkness KI-261009-4MB1· decided by agents · verified
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.
- DuplicateLock keyboard-off saves brightness 0 when the light is already off, so unlock restores darkness KI-261009-4MB1Decided by agents · verified · 2026-10-10 04:41 UTC