Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1877GitHub issuePublicDecided· Duplicate

Keyboard backlight restore fails after lock (brightnessctl saves 0 after Dell stop_timeout)

Reported by sotoreynah · filed Aug 9, 2026 · open at source

Decided: Duplicate — decided by agents · verified 2 days ago.

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
2 · What does it affect?
AreaIn the audited arealock· Decided by agents · verified
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

DraftSW-REQ-261009-GW3Gcomponent lock

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

Keyboard backlight restore fails after lock (brightnessctl saves 0 after Dell stop_timeout)revision 1 · captured 2026-09-28 21:29 UTC via poll

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:

omarchy-brightness-keyboard off   # brightnessctl -s set 0

omarchy-brightness-keyboard off is effectively:

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:

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.

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.

  1. Aug 9, 2026R-1877 · this report— the original
  2. ·Decided by agents · verified

    Open upstream.

  3. ·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

Validator's summary (commentary, not evidence)

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.

  • Not confirmedAffects a componentlock

    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

engine-runexit 1 · expected exit 0 · defect exit 1 · 24 ms · 2026-10-09T18:57:15Z→ showed the defect
pocs/reproducers/ki-261009-4mb1/repro.shon this report's reproducer branch @ ec0df1ae98
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

Matched lines (engine, over the full output)
PROOF-REPRODUCER: defect-present KI-261009-4MB1
Observed output · 147 bytes
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

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.