Onboarding keyboard list has no US/ANSI-with-accents option: "Portuguese (Brazil)" applies ABNT2 and breaks on Mac keyboards

[fabiofeichtinger]

Environment

Guest

• Try Omarchy VM — package try-omarchy-runtime 4.0.2-1 ("Pinned Basecamp Omarchy runtime 346e69e1cec6c4e8924531874af6ba010a1bc99e for the Try Omarchy guest")
• Omarchy version: 4.0.2
• Keyboard device as seen by the guest: qemu-virtio-keyboard (synthetic)

Host

• MacBook Pro, Mac16,8 — Apple M4 Pro, 12 cores (8P + 4E), 24 GB RAM, arm64
• macOS 26.6.2 (build 25G83)
• QEMU 11.0.2 (Homebrew)
• Physical keyboard: built-in Apple Internal Keyboard / Trackpad (VendorID 76, ProductID 666) — ANSI US: HID CountryCode 33 (US), KeyboardLanguage "U.S.", kbd_type 91 (ANSI family). No dedicated Ç key, no extra key left of the right Shift.
• macOS input source: "Brazilian - Pro" — the macOS layout designed for US/ANSI hardware used to write Portuguese. Accents come from dead keys (' + a = á, ' + c = ç, ~ + a = ã).

Steps to reproduce

1. Boot the Try Omarchy image on a Mac with an ANSI keyboard.
2. On the first-boot onboarding keyboard step, pick "Portuguese (Brazil)" — the only Brazilian entry in the list.
3. Finish onboarding and press the key physically labelled /.

Expected: /
Actual: ;. The / character is unreachable from its printed key.

Root cause

The keyboard picker presents a hardcoded, curated list:

• omarchy-provision-owner → keyboard_form() → omarchy_prompt_keyboard()
• defined in /usr/share/omarchy/install/provisioning/setup-form.sh:94
• list is OMARCHY_KEYBOARD_LAYOUTS, setup-form.sh:32-79 (~40 entries)

The only Brazilian entry hardcodes ABNT2 hardware:

Portuguese (Brazil)|br-abnt2

The list contains no option for US/ANSI hardware with accents:

$ sed -n '32,79p' setup-form.sh | grep -ci "intl\|acento"
0

apply_keyboard() then persists that via systemd-firstboot --keymap=, which writes both the console keymap and the XKB layout Hyprland reads:

# /etc/vconsole.conf
KEYMAP=br-abnt2
XKBLAYOUT=br
XKBMODEL=abnt2

Hyprland consumes XKBLAYOUT at default/hypr/input.lua:31.

Why the key breaks

br and us disagree on keycode 61 by design:

Keycode	XKB name	br (abnt2)	us
61	AB10	; :	/ ?
97	AB11	/ ? °	key does not exist

ABNT2 keyboards have 12 keys in the bottom row; / lives on AB11, a physical key ANSI keyboards do not have. On ANSI hardware the key labelled / is AB10 — which the br layout defines as ;. Verified with:

$ xkbcli compile-keymap --layout br --model abnt2 | grep -E "<AB10>|<AB11>"
$ xkbcli compile-keymap --layout us | grep -E "<AB10>"

The fix is one list entry away

us-acentos is already a valid console keymap on the shipped image, and systemd already maps it to exactly the right XKB config:

$ localectl list-keymaps | grep ^us
us
us-acentos
us1

$ grep -E "^(us-acentos|br-abnt2)" /usr/share/systemd/kbd-model-map
us-acentos    us    pc105    intl    terminate:ctrl_alt_bksp    -
br-abnt2      br    abnt2    -       terminate:ctrl_alt_bksp    pt-BR

us-acentos → layout us, variant intl. Applying kb_layout = "us" / kb_variant = "intl" manually in ~/.config/hypr/input.lua matches macOS "Brazilian - Pro" exactly: / works, '+e = é, '+c = ç, ~+a = ã, ^+a = â, '+space = literal '.

So the whole fix is adding an entry to OMARCHY_KEYBOARD_LAYOUTS. No change to apply_keyboard() is needed — systemd-firstboot handles the rest.

Suggested wording, since the current labels describe languages while the values encode hardware:

English (US, intl. with dead keys)|us-acentos

Why this matters for Try Omarchy specifically

Try Omarchy is a VM image made to run under QEMU on macOS. In that context the host keyboard is overwhelmingly likely to be ANSI — Apple ships ANSI hardware in Brazil, and Brazilian Mac users almost universally run "Brazilian - Pro", not ABNT2. So the one product where "Portuguese (Brazil) = ABNT2 hardware" is least likely to hold is exactly the one hardcoding it.

Auto-detection is not possible from inside the guest: qemu-virtio-keyboard is a synthetic device and does not forward the host's HID country code.

The same gap presumably affects other users whose language has a US-ANSI variant, but I only verified Brazilian Portuguese.

Requested outcome

Add at least one US/ANSI-with-accents option to the onboarding keyboard list, so users on ANSI hardware can get a working layout without editing Hyprland config by hand. Optionally, clarify in the picker that the entries select physical keyboard layout, not interface language.