Wrong language code for Norwegian keyboard layout #9489

Activity

1. janbre

   added

   bugSomething isn't workingSomething isn't working

   on Aug 31, 2026
2. janbre

   added a commit that references this issue on Aug 31, 2026

   omacom#9489 Use correct language code for Norwegian keyboard layout

   dfd8cab
3. omarchybot commented on Oct 9, 2026

   

   omarchybot

   on Oct 9, 2026

   Collaborator

   More actions

   Your diagnosis is right, and I reproduced it on a worker VM built from the Omarchy ISO (systemd 261). The ISO installer and first-boot setup both persist the chosen keymap with systemd-firstboot --keymap=…, which derives XKBLAYOUT from systemd's /usr/share/systemd/kbd-model-map. That table has a row for no but none for no-latin1. With --keymap=no-latin1, /etc/vconsole.conf gets only KEYMAP=no-latin1, and default/hypr/input.lua:31 (and the SDDM greeter's default/sddm/hyprland.lua:34) fall back to us. With --keymap=no it also gets XKBLAYOUT=no, XKBMODEL=pc105, so the desktop and the login screen come up Norwegian.

   Two open pull requests fix it with the same edit to install/provisioning/setup-form.sh, Norwegian|no-latin1 → Norwegian|no:

   • #9489 Use correct language code for Norwegian keyboard layout #9492, yours, which changes only that row and already links this issue.
   • Point six installer keymaps at ones systemd can map #11056, which makes the same change along with five other layouts that have the same problem, and drops the Lao row. I've linked it to this issue too.

   They conflict textually at the neighbouring Polish row, so only one can land as is. Each pull request is reviewed as its own item, and the maintainer will decide between them.

   One trade-off for the maintainer: the no console keymap has no dead keys and no AltGr+E for é, which no-latin1 has. That only affects the text console, such as the installer and a TTY, and not the Hyprland desktop, which uses XKB's no layout. #7049 reports the same KEYMAP=no-latin1 symptom on a Norwegian install and also covers the fcitx5 profile, which neither pull request touches.

   Codex Medium reviewed this as a second opinion. It agreed with the mechanism, which was already written down when it ran, so its independence isn't guaranteed. It contributed the console keymap difference and the conflict between the two pull requests, and I checked both. This is waiting on the maintainer.
4. cseder commented on Oct 10, 2026

   

   cseder

   on Oct 10, 2026

   More actions

   Problem for me is that after install, changing keyboard layout through the ~/.config/hypr/input.lua file, setting it to just contain "no" does not work either. After omarchy-restart-shell it still stuck on "us". It is suddenly overridden by fcitx5 or something. At least it does NOT work.
5. omarchybot commented on Oct 10, 2026

   

   omarchybot

   on Oct 10, 2026

   Collaborator

   More actions

   @cseder I couldn't reproduce that on a stock install. On a worker VM built from the Omarchy ISO (omarchy 4.0.4, Hyprland 0.56.2, fcitx5 5.1.22, with the repository at a quattro revision whose keyboard and fcitx5 files are the same as today's), I added this line to ~/.config/hypr/input.lua:

   hl.config({ input = { kb_layout = "no" } })

   Hyprland picked it up as soon as the file was saved. I then used a new virtual keyboard to press the three keys that are Ø, Æ and Å on a Norwegian keyboard, typing into a terminal, and they typed øæå. Without the line, the same keys typed ;'[. The result was the same with the omarchy-fcitx5 service running, stopped and restarted, and with fcitx5's own profile still set to keyboard-us. So fcitx5 does not override the layout set in input.lua. Omarchy ships nothing that does either: config/hypr/hyprland.lua:20 loads your input.lua after the defaults, and nothing later sets kb_layout.

   Three things could explain what you saw:

   • omarchy-restart-shell only restarts the bar and shell, not Hyprland's config. If the change didn't take, run hyprctl reload and then hyprctl configerrors, which reports a Lua error in the file if there is one. A file that contains only no is not valid config. It needs the full hl.config line above.
   • hyprctl devices lists a keyboard named hl-virtual-keyboard… that belongs to fcitx5 and always reports us. It is not the keyboard you type on. Check the entry for your physical keyboard instead.
   • If none of that helps, please post your ~/.config/hypr/input.lua, the output of hyprctl configerrors, and hyprctl devices.

   The installer bug this issue is about is unchanged. #9492 and #11056 both fix it, and choosing between them is up to the maintainer.

   Codex Medium reviewed this as a second opinion. It agreed that nothing in the source overrides the layout, after the worker result above was already known, so its independence isn't guaranteed. It pointed out that omarchy-restart-shell doesn't reload Hyprland and that fcitx5's virtual keyboard reports us. I checked both in the source.
6. cseder commented on Oct 12, 2026

   

   cseder

   on Oct 12, 2026

   Last edited by cseder

   More actions

   But was the reason for the bug chosen when the system was installed, choosing the wrongly named "no-latin1" keyboard layout at install time? Or could I have installed packages that interfere with the default way of setting up the keyboard-layout works, and maybe forces a refresh with the default values? I'll give it another go botty bot. I've heard that if I choose some similar layout (physically, like Danish 'dk') during install the normal way of editing the config isn't a problem...
7. omarchybot commented on Oct 13, 2026

   

   omarchybot

   on Oct 13, 2026

   Collaborator

   More actions

   @cseder Both, in a way, but they are separate problems. Choosing Norwegian at install time is why your desktop came up in us: that is this bug. It does not stop you changing the layout afterwards, though. Omarchy loads its own keyboard defaults first and your ~/.config/hypr/input.lua after them (config/hypr/hyprland.lua:14-20), so a valid kb_layout = "no" there wins whatever was chosen at install. Omarchy's fcitx5 config is set not to override the compositor's layout (config/fcitx5/conf/wayland.conf and xcb.conf: Allow Overriding System XKB Settings=False), and nothing else it ships writes kb_layout. The things that do replace input.lua are omarchy-refresh-hyprland and the upgrade to quattro, which both back it up and put the default back. A package that rewrote your fcitx5 config could change that setting, and I can't tell that from here.

   Danish works for a different reason. systemd's keymap table, which the installer uses to turn the console keymap into a desktop layout, has a row for dk-latin1 and none for no-latin1. So installing as Danish writes XKBLAYOUT=dk, and installing as Norwegian writes no desktop layout at all, so the desktop falls back to us. Editing your config works the same either way.

   The easiest fix on an installed system is Setup > Typing > Keyboard Layouts in the Omarchy menu (omarchy-setup-keyboard). It maps no-latin1 to no (default/input-methods/typing_setup.py:28-29), saves the choice, reloads Hyprland and checks the result. It changes the desktop only, not the console or the login screen.

   There's also news for the installer bug. Since #14431 landed on quattro on 10 October, first-boot owner setup fills in the missing layout itself: if systemd-firstboot writes no XKBLAYOUT, it appends XKBLAYOUT=no for no-latin1 (bin/omarchy-provision-owner:644 and :684-689). The ISO's own installer lives in another repository, and I can't tell from here whether it does the same. #9492 and #11056 still fix the row in install/provisioning/setup-form.sh for every path, and choosing between them is up to the maintainer.

   Everything above comes from reading the source at quattro d10031418. I didn't run anything new this time, because the worker test in my last comment already showed input.lua overriding the layout with fcitx5 running. Codex Medium reviewed it as a second opinion. My conclusions weren't in its prompt, though its independence isn't guaranteed. It found the first-boot fallback on its own and added the fcitx5 setting and the two reset paths, which I checked in the source. This is waiting on the maintainer.