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-1120GitHub issuePublicDecided· Out of scope

Default Persian (ir) keyboard layout doesn't match the Windows Persian keyboard — key above Enter types \ instead of پ

Reported by je2020je · filed Sep 1, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 days ago.

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?
AreaOutside the audited area· 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?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Default Persian (ir) keyboard layout doesn't match the Windows Persian keyboard — key above Enter types \ instead of پrevision 1 · captured 2026-09-28 21:24 UTC via poll

Description

When Persian is added as a second keyboard layout in Omarchy (Hyprland kb_layout = "us,ir"), the ir layout resolves to its default xkb variant `pes` (the newer ISIRI 9147 standard). Iranian users coming from Windows expect the legacy Windows Persian layout, which xkb ships as the ir(winkeys) variant.

The most noticeable difference:

Keyir (pes, Omarchy default)ir(winkeys) (Windows Persian)
Key above Enter (US ' label)\ (literal backslash)پ
c keyپئ

So on a default Omarchy install, pressing the key that is پ on Windows Persian keyboards types \ instead — and other keys are shifted too. This makes the out-of-the-box Persian layout feel "broken" to anyone used to Windows.

Related but separate from #9552 (that one is about fcitx5 breaking layout switching; this is about the default layout variant itself).

Steps to reproduce

  1. Set Hyprland input to kb_layout = "us,ir" (e.g. in ~/.config/hypr/input.lua) and switch to Persian.
  2. Press the key above Enter (US ' key).
  3. A \ is typed instead of پ.

Expected behavior

The Persian layout should match the Windows Persian keyboard that Iranian users are accustomed to, or at least offer it as the default variant.

Verified fix

Adding the winkeys variant fixes it:

hl.config({
  input = {
    kb_layout = "us,ir",
    kb_variant = ",winkeys",  -- Windows-style Persian layout
    kb_options = "grp:alt_shift_toggle",
  },
})

Verified working on this system — پ now types correctly from the key above Enter.

Suggested fixes (any of these)

  1. Default the Persian variant to `winkeys` when Persian is selected during setup / layout config (e.g. emit kb_variant = ",winkeys" alongside kb_layout = "us,ir").
  2. Offer a choice between "Persian (Windows)" (ir(winkeys)) and "Persian (ISIRI 9147)" (ir(pes)) in the setup wizard.
  3. Document it in the default input.lua comments so users know ir alone is ISIRI 9147, not the Windows layout.

System details

  • Omarchy 4.0.2-1 (Arch Linux, Hyprland)
  • CPU: Intel i7-7700K, GPU: NVIDIA GTX 1060 6GB
  • Keyboard: us,ir with grp:alt_shift_toggle

Full debug info: omarchy-debug --no-sudo --print (happy to upload to logs.omarchy.org if needed).

View raw text
### Description

When Persian is added as a second keyboard layout in Omarchy (Hyprland `kb_layout = "us,ir"`), the `ir` layout resolves to its default xkb variant **`pes`** (the newer ISIRI 9147 standard). Iranian users coming from Windows expect the legacy **Windows Persian layout**, which xkb ships as the `ir(winkeys)` variant.

The most noticeable difference:

| Key | `ir` (pes, Omarchy default) | `ir(winkeys)` (Windows Persian) |
|---|---|---|
| Key above Enter (US `'` label) | `\` (literal backslash) | **پ** |
| `c` key | **پ** | ئ |

So on a default Omarchy install, pressing the key that is پ on Windows Persian keyboards types `\` instead — and other keys are shifted too. This makes the out-of-the-box Persian layout feel "broken" to anyone used to Windows.

Related but separate from #9552 (that one is about fcitx5 breaking layout switching; this is about the default layout variant itself).

### Steps to reproduce

1. Set Hyprland input to `kb_layout = "us,ir"` (e.g. in `~/.config/hypr/input.lua`) and switch to Persian.
2. Press the key above Enter (US `'` key).
3. A `\` is typed instead of پ.

### Expected behavior

The Persian layout should match the Windows Persian keyboard that Iranian users are accustomed to, or at least offer it as the default variant.

### Verified fix

Adding the `winkeys` variant fixes it:

```lua
hl.config({
  input = {
    kb_layout = "us,ir",
    kb_variant = ",winkeys",  -- Windows-style Persian layout
    kb_options = "grp:alt_shift_toggle",
  },
})
```

Verified working on this system — پ now types correctly from the key above Enter.

### Suggested fixes (any of these)

1. **Default the Persian variant to `winkeys`** when Persian is selected during setup / layout config (e.g. emit `kb_variant = ",winkeys"` alongside `kb_layout = "us,ir"`).
2. **Offer a choice** between "Persian (Windows)" (`ir(winkeys)`) and "Persian (ISIRI 9147)" (`ir(pes)`) in the setup wizard.
3. **Document it** in the default `input.lua` comments so users know `ir` alone is ISIRI 9147, not the Windows layout.

### System details

- Omarchy 4.0.2-1 (Arch Linux, Hyprland)
- CPU: Intel i7-7700K, GPU: NVIDIA GTX 1060 6GB
- Keyboard: `us,ir` with `grp:alt_shift_toggle`

Full debug info: `omarchy-debug --no-sudo --print` (happy to upload to logs.omarchy.org if needed).

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.

  • Out of scopeDecided by agents · verified · 2026-10-09 10:24 UTC