Proof Portal

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

Weird behaviour with multiple keyboard layouts

Reported by ablluu · filed Feb 11, 2026 · open at source

Open at source

Decided: Out of scope — decided by agents · verified 4 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

Weird behaviour with multiple keyboard layoutsrevision 1 · captured 2026-09-28 21:29 UTC via poll

System details

Intel(R) Core(TM) Ultra 5 125U, Omarchy 3.3.3

What's wrong?

My Laptop has a German ISO layout and i bought a keyboard that is US ANSI. So i need to run two kb layouts in the input config:

kb_layout = de, us
kb_variant = nodeadkeys,altgr-intl
kb_options = grp:ctrls_toggle, compose:caps

Thisd worked but at random intervals (no obvious pattern, like media keys, per window, per workspace) it just switched back. I mad myself a waybar config to see the active layout

  "hyprland/language": {
    "format": "{}",
    "format-en": "US",
    "format-de": "DE",
    "on-click": "hyprctl switchxkblayout at-translated-set-2-keyboard next",
    "tooltip-format": "{long}"
  }

This showed that only while typing was the language set to US, immidietaly when moving the mouse out of the window it switched back to the default

Then i found that fcitx5 was running that seems to be a tool that manages keyboard layouts and it had to be conflicting with the wy hyprland normally does things.
Since i have not really installed any programs in that direction and it appears in various config files i will assume it is some part of omarchy?

There is a workaround, just kill the process, one can write this into the autostart.

Please advise on whether not running this could cause other issues?

View raw text

### System details

Intel(R) Core(TM) Ultra 5 125U, Omarchy 3.3.3

### What's wrong?

My Laptop has a German ISO layout and i bought a keyboard that is US ANSI. So i need to run two kb layouts in the input config:

```
kb_layout = de, us
kb_variant = nodeadkeys,altgr-intl
kb_options = grp:ctrls_toggle, compose:caps
```

Thisd worked but at random intervals (no obvious pattern, like media keys, per window, per workspace) it just switched back. I mad myself a waybar config to see the active layout 

```
  "hyprland/language": {
    "format": "{}",
    "format-en": "US",
    "format-de": "DE",
    "on-click": "hyprctl switchxkblayout at-translated-set-2-keyboard next",
    "tooltip-format": "{long}"
  }
```

This showed that only while typing was the language set to US, immidietaly when moving the mouse out of the window it switched back to the default

Then i found that fcitx5 was running that seems to be a tool that manages keyboard layouts and it had to be conflicting with the wy hyprland normally does things.
Since i have not really installed any programs in that direction and it appears in various config files i will assume it is some part of omarchy?

There is a workaround, just kill the process, one can write this into the autostart.

Please advise on whether not running this could cause other issues?

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 02:36 UTC

Proof

History & reports

Reference