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.
SDDM greeter ignores system keyboard layout (always US, breaks AZERTY at login/lock screen)
Reported by tecknozic · filed Sep 6, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #6880 (R-1858). GitHub close reason: completed.
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: QEMU/aarch64 VM (virtio GPU), Omarchy 4.0.2-4, Hyprland 0.56.1, SDDM 0.21.0-7, keyboard set to AZERTY (fr) via localectl//etc/vconsole.conf.
What's wrong?
The SDDM greeter (login screen shown at boot, and any screen shown before a session is opened) always uses a US keyboard layout, ignoring the system's configured layout (AZERTY/fr here). This makes it easy to mistype your password at the login/lock screen, especially with special characters that differ between layouts.
Root cause
SDDM's Hyprland greeter compositor config, shipped by omarchy-settings at /usr/share/sddm/hyprland.lua, sets up keyboard input but never reads the system keymap (/etc/vconsole.conf / XKBLAYOUT). By contrast, the user session's own ~/.config/hypr/input.lua does read vconsole.XKBLAYOUT (falling back to us). Because the greeter config never does this, it always falls back to us regardless of the machine's actual layout.
Steps to reproduce
- Install Omarchy and set the console/system keyboard layout to something other than US, e.g.
sudo localectl set-keymap fr(AZERTY). - Reboot, or log out to return to SDDM.
- At the SDDM login screen, type a character that differs between layouts (e.g.
q,a,w,m). - Observe that the character typed corresponds to a US layout, not the configured one.
Workaround (tested, works)
Since /usr/share/sddm/hyprland.lua is overwritten by omarchy update / omarchy refresh sddm, patch around it instead of in place:
- Copy
/usr/share/sddm/hyprland.luato/etc/sddm/greeter-hyprland.lua, and inject a read of/etc/vconsole.conf(XKBLAYOUT/XKBVARIANT/XKBMODEL/XKBOPTIONS) into thehl.config({ input = {...} })block, the same way~/.config/hypr/input.luaalready does for the user session. - Add a drop-in
/etc/sddm.conf.d/20-keyboard-fix.conf:
[Wayland]
CompositorCommand=start-hyprland -- --config /etc/sddm/greeter-hyprland.lua (loaded after 10-wayland.conf — sddm merges sddm.conf.d/*.conf alphabetically, last write per key wins.)
Both files live under /etc, so they survive omarchy update and omarchy refresh sddm.
Confirmed fixed on this system: AZERTY now types correctly at the SDDM login screen after applying the above.
Suggested proper fix
Have the shipped /usr/share/sddm/hyprland.lua (or the SDDM package config Omarchy generates) read /etc/vconsole.conf the same way ~/.config/hypr/input.lua does, so the greeter matches the system's keyboard layout out of the box.
View raw text
**System details:** QEMU/aarch64 VM (virtio GPU), Omarchy 4.0.2-4, Hyprland 0.56.1, SDDM 0.21.0-7, keyboard set to AZERTY (`fr`) via `localectl`/`/etc/vconsole.conf`.
**What's wrong?**
The SDDM greeter (login screen shown at boot, and any screen shown before a session is opened) always uses a US keyboard layout, ignoring the system's configured layout (AZERTY/`fr` here). This makes it easy to mistype your password at the login/lock screen, especially with special characters that differ between layouts.
**Root cause**
SDDM's Hyprland greeter compositor config, shipped by `omarchy-settings` at `/usr/share/sddm/hyprland.lua`, sets up keyboard input but never reads the system keymap (`/etc/vconsole.conf` / `XKBLAYOUT`). By contrast, the user session's own `~/.config/hypr/input.lua` does read `vconsole.XKBLAYOUT` (falling back to `us`). Because the greeter config never does this, it always falls back to `us` regardless of the machine's actual layout.
**Steps to reproduce**
1. Install Omarchy and set the console/system keyboard layout to something other than US, e.g. `sudo localectl set-keymap fr` (AZERTY).
2. Reboot, or log out to return to SDDM.
3. At the SDDM login screen, type a character that differs between layouts (e.g. `q`, `a`, `w`, `m`).
4. Observe that the character typed corresponds to a US layout, not the configured one.
**Workaround (tested, works)**
Since `/usr/share/sddm/hyprland.lua` is overwritten by `omarchy update` / `omarchy refresh sddm`, patch around it instead of in place:
- Copy `/usr/share/sddm/hyprland.lua` to `/etc/sddm/greeter-hyprland.lua`, and inject a read of `/etc/vconsole.conf` (`XKBLAYOUT`/`XKBVARIANT`/`XKBMODEL`/`XKBOPTIONS`) into the `hl.config({ input = {...} })` block, the same way `~/.config/hypr/input.lua` already does for the user session.
- Add a drop-in `/etc/sddm.conf.d/20-keyboard-fix.conf`:
```
[Wayland]
CompositorCommand=start-hyprland -- --config /etc/sddm/greeter-hyprland.lua
```
(loaded after `10-wayland.conf` — sddm merges `sddm.conf.d/*.conf` alphabetically, last write per key wins.)
Both files live under `/etc`, so they survive `omarchy update` and `omarchy refresh sddm`.
Confirmed fixed on this system: AZERTY now types correctly at the SDDM login screen after applying the above.
**Suggested proper fix**
Have the shipped `/usr/share/sddm/hyprland.lua` (or the SDDM package config Omarchy generates) read `/etc/vconsole.conf` the same way `~/.config/hypr/input.lua` does, so the greeter matches the system's keyboard layout out of the box.
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.