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-419GitHub issuePublicFixed

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

Partly in the audited area (lock) — decided by agents · verified. Not validated yet.

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?
AreaPartly in the audited arealock· 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?
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

Keyboard backlight unexpectedly turns back on after idle wake or unlockrevision 1 · captured 2026-09-28 21:23 UTC via poll

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:

# /usr/share/omarchy/bin/omarchy-system-wake
omarchy-brightness-keyboard restore

The lock plugin turns the keyboard backlight off with:

# /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.

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

  1. Sep 17, 2026R-419 · this report— tracked here
  2. ·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.