I installed EOS bspwm edition, using Greek locale and keyboard in Calamares.
Calamares installs /etc/default/{keyboard,locale} and /etc/X11/xorg.conf.d/00-keyboard.conf, with settings that Arch and systemd keep at /etc/X11/xorg.conf.d/00-keyboard.conf and /etc/{locale,vconsole}.conf.
/etc/X11/xorg.conf.d/00-keyboard.conf was correctly populated with both us,gr layouts, while /etc/default/keyboard had only gr layout.
Slick-greeter seems that it is reading /etc/default/keyboard only, leading to inability for keyboard layout switch, thus I could not switch to English to type my password.
Until I realize the issue, my quick solution was to replace lightdm with sddm, using TTY, where keyboards were working correctly.
SDDM worked as expected OOTB.
Non-English locale/keyboard systems will have problems (if they don’t already) with slick-greeter, since Archwiki instructions do not mention any locale/keyboard settings in /etc/default/. If a user changes locale/keyboard settings after installation, the DM does not follow. In my case, it was stuck to the Greek keyboard, without the toggle switch working. It is a slick-greeter known bug.
I haven’t tested if it will work after deleting those /etc/default/ files, although I suspect it will not (due to some error messages).
I would suggest switching to SDDM or other option, that would behave adequately for non-English/multi-locale systems.
Speaking about multiple keyboard layouts,
- the proper vconsole settings for non-latin systems would be:
KEYMAP=us # Primary layout
KEYMAP_TOGGLE=gr # Secondary layout, with toggle switch
FONT=eurlatgr # Safe font for Greek, cyrillic and others (better than square blocks...)
- proper local/user settings for locale setting is using
$HOME/.config/locale.confwith user preferences, relevant to/etc/locale.confand adding this in$HOME/.bashrc(or other shellrc)
unset LANG # reset, because it cannot change while is already set
source /etc/profile.d/locale.sh
According to Archwiki
Using Calamares is not foolproof (at all!). Why not adapting one of the many CLI installers, that can be hacked way more easilly?
