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.
Hibernate pre-sleep hook kills keyboard backlight permanently (no post-resume restore)
Reported by xRiErOS · filed Sep 20, 2026 · open at source
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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
What happens: /usr/share/omarchy/default/systemd/system-sleep/keyboard-backlight forces the keyboard backlight to 0 before every hibernate via brightnessctl (comment: workaround for an S4 power-off hang on ASUS keyboard controllers). The glob /sys/class/leds/*kbd_backlight* matches any *kbd_backlight* LED device though, not just ASUS ones — e.g. tpacpi::kbd_backlight on a ThinkPad. There is only a pre branch, no post counterpart. Result: the keyboard backlight stays off permanently after every hibernate resume, and because systemd-backlight@leds:...service persists the current (now 0) value on the next real shutdown, it stays off after regular reboots too.
Expected: The backlight should be restored to its previous value after resume, or the workaround should be scoped to hardware that actually has the S4 hang (ASUS-specific LED paths) instead of every *kbd_backlight* device.
Steps to reproduce:
1. On a device with tpacpi::kbd_backlight (or any non-ASUS *kbd_backlight* device), turn the keyboard backlight on.
2. systemctl hibernate, then resume.
3. Keyboard backlight is off and stays off, including after a subsequent full reboot.
System: Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, ThinkPad X1 Carbon Gen 12.
Suggested fix: Save the pre-hibernate brightness to a state file and restore it in a post branch, or scope the zero-out workaround to ASUS-specific LED device names (e.g. asus::kbd_backlight) instead of the generic *kbd_backlight* glob.
View raw text
**What happens:** `/usr/share/omarchy/default/systemd/system-sleep/keyboard-backlight` forces the keyboard backlight to 0 before every hibernate via `brightnessctl` (comment: workaround for an S4 power-off hang on ASUS keyboard controllers). The glob `/sys/class/leds/*kbd_backlight*` matches any `*kbd_backlight*` LED device though, not just ASUS ones — e.g. `tpacpi::kbd_backlight` on a ThinkPad. There is only a `pre` branch, no `post` counterpart. Result: the keyboard backlight stays off permanently after every hibernate resume, and because `systemd-backlight@leds:...service` persists the current (now 0) value on the next real shutdown, it stays off after regular reboots too. **Expected:** The backlight should be restored to its previous value after resume, or the workaround should be scoped to hardware that actually has the S4 hang (ASUS-specific LED paths) instead of every `*kbd_backlight*` device. **Steps to reproduce:** 1. On a device with `tpacpi::kbd_backlight` (or any non-ASUS `*kbd_backlight*` device), turn the keyboard backlight on. 2. `systemctl hibernate`, then resume. 3. Keyboard backlight is off and stays off, including after a subsequent full reboot. **System:** Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, ThinkPad X1 Carbon Gen 12. **Suggested fix:** Save the pre-hibernate brightness to a state file and restore it in a `post` branch, or scope the zero-out workaround to ASUS-specific LED device names (e.g. `asus::kbd_backlight`) instead of the generic `*kbd_backlight*` glob.
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/13005· 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.
- Out of scopeDecided by agents · verified · 2026-10-09 19:20 UTC