Proof Portal

Sign in
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-177GitHub issuePublicFixed

Keyboard layout and keyboard backlight don't persist across suspend/resume

Reported by efecege · filed Sep 23, 2026 · open at source

Open at source
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 layout and keyboard backlight don't persist across suspend/resumerevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened: After a real suspend/resume (not just idle lock), the active keyboard layout reverts to the first configured layout, and the keyboard backlight stays off, with nothing restoring either automatically.

Traced the cause in the shell source: plugins/lock/Service.qml's idleBlankTimer explicitly re-arms instead of blanking when the gap since it was armed exceeds ~7s, specifically to avoid blanking a freshly-woken screen after a long suspend — but nothing takes over restoring backlight for that case, so it just never gets restored. Keyboard layout is a separate gap: Hyprland's per-device layout state on the real keyboard doesn't survive the device's suspend/resume cycle, and nothing re-applies the previous layout afterward (omarchy-system-wake only runs on idle-cycle-cancel / lock-unlock, not tied to PrepareForSleep).

Expected: Both keyboard layout and keyboard backlight are restored to their pre-suspend state after resume.

Steps to reproduce: Switch keyboard layout and/or turn on keyboard backlight, suspend, resume.

Workaround found: A user-level service that listens for org.freedesktop.login1.Manager.PrepareForSleep directly (holding a systemd-inhibit --mode=delay lock while capturing pre-sleep state, same pattern omarchy-system-sleep-monitor uses) and restores both after resume.

System: Omarchy 4.0.4-1 (quattro), Hyprland 0.56.2-2, brightnessctl 0.5.1-3, kernel 7.2.3-arch1-3. Lenovo 20QDS3DT00 (ThinkPad).

View raw text
**What happened:** After a real suspend/resume (not just idle lock), the active keyboard layout reverts to the first configured layout, and the keyboard backlight stays off, with nothing restoring either automatically.

Traced the cause in the shell source: `plugins/lock/Service.qml`'s `idleBlankTimer` explicitly re-arms instead of blanking when the gap since it was armed exceeds ~7s, specifically to avoid blanking a freshly-woken screen after a long suspend — but nothing takes over restoring backlight for that case, so it just never gets restored. Keyboard layout is a separate gap: Hyprland's per-device layout state on the real keyboard doesn't survive the device's suspend/resume cycle, and nothing re-applies the previous layout afterward (`omarchy-system-wake` only runs on idle-cycle-cancel / lock-unlock, not tied to `PrepareForSleep`).

**Expected:** Both keyboard layout and keyboard backlight are restored to their pre-suspend state after resume.

**Steps to reproduce:** Switch keyboard layout and/or turn on keyboard backlight, suspend, resume.

**Workaround found:** A user-level service that listens for `org.freedesktop.login1.Manager.PrepareForSleep` directly (holding a `systemd-inhibit --mode=delay` lock while capturing pre-sleep state, same pattern `omarchy-system-sleep-monitor` uses) and restores both after resume.

**System:** Omarchy 4.0.4-1 (quattro), Hyprland 0.56.2-2, brightnessctl 0.5.1-3, kernel 7.2.3-arch1-3. Lenovo 20QDS3DT00 (ThinkPad).

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/13227· confirmed
  • Related PRpr/13156· confirmed
  • Related PRpr/12502· confirmed
  • Related PRpr/5839· confirmed
  • Related PRpr/8119· confirmed
  • 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.

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