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 unexpectedly turns back on after idle wake or unlock
Reported by AnoopLamba · filed Sep 17, 2026Closed upstream on 2026-10-12 by the bot omarchybot, as a duplicate (target not recorded).
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?
- 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. So far: partly in the audited area (lock) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
What happened
When I manually turn the keyboard backlight off, Omarchy turns it back on after the idle screen saver is dismissed or the lock screen is unlocked. This is confusing because the user explicitly selected off.
Steps to reproduce
- On a laptop with a multi-level keyboard backlight, turn the keyboard backlight off using the keyboard shortcut.
- Let the Omarchy idle screen saver/lock activate, or otherwise start an idle cycle.
- Move the mouse/press a key to wake the session, or unlock it.
- The keyboard backlight turns on again without the user requesting it.
Expected behavior
An explicit user choice to turn the keyboard backlight off should remain off until the user changes it. Wake/unlock should not restore an earlier on-state over a later user choice.
Findings / suspected cause
The wake path unconditionally restores the previously saved keyboard brightness:
# /usr/share/omarchy/bin/omarchy-system-wake
omarchy-brightness-keyboard restoreThe lock plugin turns the keyboard backlight off with:
# /usr/share/omarchy/shell/plugins/lock/Service.qml
omarchy-brightness-keyboard offomarchy-brightness-keyboard off uses brightnessctl -s before setting brightness to zero, while the normal keyboard-backlight shortcut uses the cycle path and does not update that saved restore value. Consequently, a later omarchy-system-wake can restore the old on-state after the user has manually turned the backlight off.
The idle service calls the wake process when an idle cycle is cancelled, and the lock service calls it after unlock. The current brightnessctl restore state for this device is 1, confirming that an on-state is available to be restored.
System information
- Omarchy: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- Compositor: Hyprland 0.56.2
- Hardware: Lenovo IdeaPad 330S-14IKB U (81F4)
- BIOS: 7SCN21WW (2018-07-31)
The ideapad_laptop driver is loaded, the keyboard backlight device is detected, and there are no Hyprland configuration errors. The hardware supports multiple levels, although the generic sysfs interface currently reports only a binary 0/1 range.
View raw text
## What happened When I manually turn the keyboard backlight off, Omarchy turns it back on after the idle screen saver is dismissed or the lock screen is unlocked. This is confusing because the user explicitly selected **off**. ## Steps to reproduce 1. On a laptop with a multi-level keyboard backlight, turn the keyboard backlight off using the keyboard shortcut. 2. Let the Omarchy idle screen saver/lock activate, or otherwise start an idle cycle. 3. Move the mouse/press a key to wake the session, or unlock it. 4. The keyboard backlight turns on again without the user requesting it. ## Expected behavior An explicit user choice to turn the keyboard backlight off should remain off until the user changes it. Wake/unlock should not restore an earlier on-state over a later user choice. ## Findings / suspected cause The wake path unconditionally restores the previously saved keyboard brightness: ```bash # /usr/share/omarchy/bin/omarchy-system-wake omarchy-brightness-keyboard restore ``` The lock plugin turns the keyboard backlight off with: ```bash # /usr/share/omarchy/shell/plugins/lock/Service.qml omarchy-brightness-keyboard off ``` `omarchy-brightness-keyboard off` uses `brightnessctl -s` before setting brightness to zero, while the normal keyboard-backlight shortcut uses the cycle path and does not update that saved restore value. Consequently, a later `omarchy-system-wake` can restore the old on-state after the user has manually turned the backlight off. The idle service calls the wake process when an idle cycle is cancelled, and the lock service calls it after unlock. The current `brightnessctl` restore state for this device is `1`, confirming that an on-state is available to be restored. ## System information - Omarchy: 4.0.3-1 - Kernel: 7.2.3-arch1-3 - Compositor: Hyprland 0.56.2 - Hardware: Lenovo IdeaPad 330S-14IKB U (81F4) - BIOS: 7SCN21WW (2018-07-31) The `ideapad_laptop` driver is loaded, the keyboard backlight device is detected, and there are no Hyprland configuration errors. The hardware supports multiple levels, although the generic sysfs interface currently reports only a binary `0/1` range.
Also reported as
This defect is tracked under R-419 (filed Sep 17, 2026). 1 other report describes the same defect.
Earliest report of this defect: R-839 (filed Sep 8, 2026).
- Sep 17, 2026R-419 · this report— tracked here
- ·Decided by agents · verified
Open upstream.
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
- Related PRpr/8119· confirmed
- Fixed bypr/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.
- Decided by agents · verified: partly in the audited area (lock)
- Decided by agents · verified: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.