Setting keyboard layout doesn't translate over to X11

[Torxed]

installation.set_keyboard_language does not translate over to desktop environments as discussed with @phisch.
Traditionally I would have created something in '/etc/X11/xinit/xinit.rcwithsetxkbmap se` or similar.

But something like:

$ localectl set-keymap "" && localectl set-keymap de
$ localectl set-keymap de && localectl set-x11-keymap de

Would work, we need to investigate how this translates over to sddm, gdm and xinit.

---

To get the currently supported list, I suggest using localectl list-keymaps and localectl list-x11-keymap-layouts.
As pointed out by @phisch:

VC and X11 keymaps are also different standards

The "languages" if you will don't follow the same naming convention, making it ridiculously hard to make a one-shot-function to set these things. Either we'll need to ask the user two times for language selection, or manually keep a translation table up to date (I see this backfiring in the future). We would only need to ask users twice if they opted in for a desktop environment tho, which most new users probably would do.

Any suggestions on how to solve this as cleanly as possible are welcome.

[grazzolini]

localectl sets things on /etc/X11/xorg.conf.d as well as it deals with /etc/vsoncole.conf and /etc/locale.conf. In my opinion is the cleanest solution to manage keyboard layouts and locales in a consistent way. We have to keep in mind that localectl doesn't touch any wayland setting, but usually those are compositor dependent.

[phisch]

Not exactly sure about the specific case, but i ran into an issue on a system when running arch_chroot(f'localectl set-x11-keymap {KEYMAP}') because apparently the keymap was not available. Running the same command after the installation worked fine though. So i am not sure if something other than installing xorg-server is necessary for this to work properly.

[grazzolini]

Not exactly sure about the specific case, but i ran into an issue on a system when running arch_chroot(f'localectl set-x11-keymap {KEYMAP}') because apparently the keymap was not available. Running the same command after the installation worked fine though. So i am not sure if something other than installing xorg-server is necessary for this to work properly.

I think the issue here is that X must be installed before running this command. So, localectl stuff should be ran after package installation.

[phisch]

Yeah i thought so too, but i ran into this issue after installing the x11 packages.
Reverted it until i figure out why it causes an issue.
phisch/dotfiles@16feb27

[Torxed]

Yeah i thought so too, but i ran into this issue after installing the x11 packages.
Reverted it until i figure out why it causes an issue.
phisch/dotfiles@16feb27

I'm thinking that this might help: /usr/bin/systemd-nspawn -D /mnt --machine temporary. And I was planning on adding it back anyway:
https://github.com/Torxed/archinstall/blob/59994c1ffdcc916f782d50e248316790fec70974/archinstall.py#L1117

Not sure why it got lost. But that will most likely solve the issue, albeit a bit overkill if there's a simpler solution.
@phisch if you have the time and machine for it, could you try:

(live cd)# systemd-nspawn -D /mnt --machine temporary /bin/bash -c 'localectl set-x11-keymap de'

And see if that does anything different.
I also saw this today:

Unless the --no-convert option is passed, the specified keymap is also converted to the closest matching console keymap and applied to the console configuration in vconsole.conf

So it should set a tty console layout as well, so there shouldn't be a need to call localectl set-keymap de assuming x11 is installed and you're running it from a "booted system" :)

[Torxed]

Because this was created before the move, I can't link the PR that would solve this, which is #443 :)
It's a WIP for now (forgot to mark it), but that should resolve this issue.

[Torxed]

So the only real issue I phase right now, is the inconsistency between x11 and vconsole.

• vconsole expects sv-latin1
• x11 expects se
  And this is for the same keymap/layout.

localectl list-keymaps differ from localectl list-x11-keymap-layouts for this very reason.
Currently, I'm thinking that x11 keymaps are ignored and only set if a desktop profile is used, and if that's the case we'll add one additional question for what keyboard layout they wish to use.. Because I can't find a reliable way of mapping between the two.

[phisch]

set-keymap MAP [TOGGLEMAP]
    Set the system keyboard mapping for the console and X11. This takes a mapping name (such
    as "de" or "us"), and possibly a second one to define a toggle keyboard mapping. Unless
    --no-convert is passed, the selected setting is also applied as the default system
    keyboard mapping of X11, after converting it to the closest matching X11 keyboard
    mapping. Use list-keymaps for a list of available keyboard mappings (see below).

This somehow sets the keymap for both x11 and vc, BUT from my testing, this only works after the locale has been set to an empty string. So, running localectl set-keymap "" && localectl set-keymap "de".
No idea how good their mapping is, i mean how much can you trust an application that doesn't even do what it says on the first try? Would like to read the source code of localectl at some point to be 100% certain of what is going on here.

[Torxed]

Forgot about the empty trick. I'll give that a go, that way we don't have to ask for it twice - which eliminates the only issue I have at the moment in the PR.

[Torxed]

For whatever reason, it doesn't seam that localectl works at all with chroot environments.
The current code in:

archinstall/archinstall/lib/installer.py

Lines 525 to 530 in 8ab145d

	# In accordance with https://github.com/archlinux/archinstall/issues/107#issuecomment-841701968
	# Setting an empty keymap first, allows the subsequent call to set layout for both console and x11.
	self.arch_chroot('localectl set-keymap ""')
	if (output := self.arch_chroot(f'localectl set-keymap {language}')).exit_code != 0:
	raise ServiceException(f"Unable to set locale '{language}' for console: {output}")

Appears to "work" in the sense that it executes, and no errors are given.
And locale is set outside in the installation medium (ISO), but not in the installation itself.

Appears to be a known issue/design-choice because of the dbus usage. I'll fix that : )