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.
Lock screen accepts no keyboard input after suspend/resume — fcitx5 wedges, presents as a system freeze
Reported by brendanhalfpenny · filed Aug 31, 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?
- 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: in the audited area (lock) — decided by agents · verified; matches no known issue — decided by arbitration. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
What happened
After suspend/resume, the lock screen accepts no keyboard input at all: the password field shows a blinking cursor but every keystroke vanishes. To a user this is indistinguishable from a full system freeze — I cold-booted the machine twice before finding the real cause.
The system is actually healthy: Hyprland stays responsive (hyprctl works), network is up, and the journal shows a clean resume. The problem is that fcitx5 wedges across suspend, and the Quickshell lock screen's password field routes text input through it (QT_IM_MODULE=fcitx is set session-wide), so a wedged fcitx5 silently eats all typing at the exact moment the user must type.
Restarting Omarchy's managed unit brings input back instantly:
systemctl --user restart omarchy-fcitx5.serviceSteps to reproduce
- Default Omarchy install (fcitx5 enabled via
omarchy-fcitx5.service) - Suspend (lid close), leave suspended for a while, resume
- Try to type at the lock screen
Reproduced on multiple suspend cycles, including ones with a completely clean journal (no GPU/driver errors), so it is not tied to graphics resume. Wedge frequency was intermittent-to-frequent across one day of testing (3 of 5 cycles).
Expected
Lock screen accepts the password after resume, or fcitx5 survives (or is restarted after) suspend.
Workaround that fixed it permanently here
A user service watching logind's PrepareForSleep signal, restarting omarchy-fcitx5.service ~1s after each resume. Since Omarchy already ships system-sleep hooks (e.g. keyboard-backlight), shipping an equivalent resume-restart for fcitx5 might be the simplest fix.
Note: restarting via a raw fcitx5 -rd instead of the unit makes things worse — it takes over the D-Bus name and omarchy-fcitx5.service (Restart=always) then crash-loops every 2 seconds indefinitely.
System details
- Omarchy 4.0.1, Hyprland 0.56.2, fcitx5 5.1.21-1, quickshell 0.3.1-1
- ASUS ROG Strix G18 (G815LR), Intel Core Ultra 9 275HX
- NVIDIA RTX 5070 Ti Laptop, driver 610.57.04 (nvidia-open-dkms), MUX/dGPU mode (
AsusMuxDgpu) - Suspend is s2idle;
omarchy debugis not present in 4.0.1 so happy to provide any logs on request
View raw text
## What happened After suspend/resume, the lock screen accepts no keyboard input at all: the password field shows a blinking cursor but every keystroke vanishes. To a user this is indistinguishable from a full system freeze — I cold-booted the machine twice before finding the real cause. The system is actually healthy: Hyprland stays responsive (`hyprctl` works), network is up, and the journal shows a clean resume. The problem is that **fcitx5 wedges across suspend**, and the Quickshell lock screen's password field routes text input through it (`QT_IM_MODULE=fcitx` is set session-wide), so a wedged fcitx5 silently eats all typing at the exact moment the user must type. Restarting Omarchy's managed unit brings input back instantly: ``` systemctl --user restart omarchy-fcitx5.service ``` ## Steps to reproduce 1. Default Omarchy install (fcitx5 enabled via `omarchy-fcitx5.service`) 2. Suspend (lid close), leave suspended for a while, resume 3. Try to type at the lock screen Reproduced on multiple suspend cycles, including ones with a completely clean journal (no GPU/driver errors), so it is not tied to graphics resume. Wedge frequency was intermittent-to-frequent across one day of testing (3 of 5 cycles). ## Expected Lock screen accepts the password after resume, or fcitx5 survives (or is restarted after) suspend. ## Workaround that fixed it permanently here A user service watching logind's `PrepareForSleep` signal, restarting `omarchy-fcitx5.service` ~1s after each resume. Since Omarchy already ships system-sleep hooks (e.g. `keyboard-backlight`), shipping an equivalent resume-restart for fcitx5 might be the simplest fix. Note: restarting via a raw `fcitx5 -rd` instead of the unit makes things worse — it takes over the D-Bus name and `omarchy-fcitx5.service` (Restart=always) then crash-loops every 2 seconds indefinitely. ## System details - Omarchy 4.0.1, Hyprland 0.56.2, fcitx5 5.1.21-1, quickshell 0.3.1-1 - ASUS ROG Strix G18 (G815LR), Intel Core Ultra 9 275HX - NVIDIA RTX 5070 Ti Laptop, driver 610.57.04 (nvidia-open-dkms), MUX/dGPU mode (`AsusMuxDgpu`) - Suspend is s2idle; `omarchy debug` is not present in 4.0.1 so happy to provide any logs on request
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
Not linked to any known issue, other report or change yet.
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: in the audited area (lock)
- Decided by arbitration: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.