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.
Hyprlock uses QWERTY layout after update to 3.8.0 despite system layout being AZERTY
Reported by drissmoslih · filed May 11, 2026Closed upstream on 2026-07-18 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
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?
- Not yet mapped to any requirement or component.
- 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. No decision has been recorded yet.
Original report
System details
Dell laptop, Omarchy 3.8.0
What's wrong?
After updating Omarchy to 3.8.0, I noticed that hyprlock no longer uses my configured keyboard layout.
My system is configured with the fr AZERTY layout, and everything was working correctly before the update.
What happens now:
- the LUKS password prompt still uses the correct AZERTY layout,
- but once the
hyprlockscreen appears, my password is rejected withlogin failedeven though it is correct.
I eventually realized that hyprlock is behaving as if the keyboard were using a US QWERTY layout. If I type the password using QWERTY key positions, login succeeds.
After logging in, the desktop session itself still correctly uses AZERTY, so the update does not seem to have modified my keyboard configuration. My ~/.config/hypr/input.conf is still correct, and the layout works normally everywhere else.
Steps to reproduce
- Configure the keyboard layout as
fr(AZERTY) - Update Omarchy to 3.8.0
- Reboot
- Unlock LUKS normally using AZERTY
- At the
hyprlockscreen, enter the password normally using AZERTY → fails - Enter the same password using QWERTY mapping instead → succeeds
Expected behavior
hyprlock should use the configured keyboard layout (fr / AZERTY), just like the rest of the system.
View raw text
### System details Dell laptop, Omarchy 3.8.0 ### What's wrong? After updating Omarchy to 3.8.0, I noticed that `hyprlock` no longer uses my configured keyboard layout. My system is configured with the `fr` AZERTY layout, and everything was working correctly before the update. What happens now: * the LUKS password prompt still uses the correct AZERTY layout, * but once the `hyprlock` screen appears, my password is rejected with `login failed` even though it is correct. I eventually realized that `hyprlock` is behaving as if the keyboard were using a US QWERTY layout. If I type the password using QWERTY key positions, login succeeds. After logging in, the desktop session itself still correctly uses AZERTY, so the update does not seem to have modified my keyboard configuration. My `~/.config/hypr/input.conf` is still correct, and the layout works normally everywhere else. ### Steps to reproduce 1. Configure the keyboard layout as `fr` (AZERTY) 2. Update Omarchy to 3.8.0 3. Reboot 4. Unlock LUKS normally using AZERTY 5. At the `hyprlock` screen, enter the password normally using AZERTY → fails 6. Enter the same password using QWERTY mapping instead → succeeds ### Expected behavior `hyprlock` should use the configured keyboard layout (`fr` / AZERTY), just like the rest of the system.
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.
No decision has been recorded yet.