On Thu, 2025-04-24 at 00:25 +0200, Jocelyn Falempe wrote: > > > > > > > > (but on a serious level, how does configuring keyboard layout / input > > > > method work if all you have is a compositor and a terminal app? > > > > presumably read from a file...has the format and location been > > > > standardized?) > > > > > > systemd has the localectl command to do that, it also generates a file > > > /etc/vconsole.conf which has the keymap information. > > > > Hmm, but this is still problematic. localectl can *set* both console > > (kbd) layouts and a xkb layouts, but AFAIK like it only ever writes a > > kbd layout name to /etc/vconsole.conf . It has a ridiculous lookup > > table for converting between the two on various operations - so it can > > try to set a 'matching' xkb configuration for whatever kbd layout is > > specified in vconsole.conf - but this is buggy and restricted. This > > whole mess is what I would like to kill. I would love to get to a > > situation where we *only* care about xkb layouts, and that's the config > > we write. > > Ok so if I understand correctly, xkb is what localectl calls x11, and > kbd is the vconsole keymap?
Yeah (AIUI anyway). xkb - http://www.freedesktop.org/wiki/Software/XKeyboardConfig . kbd - https://github.com/legionus/kbd . things get a bit complicated with 'xkb' because in real X11, the X server itself (AIUI) does the work of loading layouts and handling switches and so on. Wayland uses xkb layouts and libxkbcommon, but not in the same way. The top-rated answer to https://unix.stackexchange.com/questions/309580/ explains it better than I can. > > > When trying with Gnome-kiosk or Kwin, the layout is automatically > > > configured (I use dvorak, and it was already setup without any > > > interaction). > > > For Kmscon, you need to edit the file /etc/kmscon.conf. > > > And for Cage + foot, I've done a workaround, to read the configuration > > > from /etc/vconsole.conf with [1], and export the XKB_DEFAULT_LAYOUT > > > variable. > > > I can probably do the same for kmscon, or read directly > > > /etc/vconsole.conf in kmscon. > > > > > > [1] > > > https://gitlab.com/kdj0c/userspacevt/-/blob/main/cagefootvt/usr/libexec/cagefootvt/wait_tty.sh?ref_type=heads#L11 > > > > I suspect if you try this on a Russian install, you will find you can't > > type any ASCII characters. > > So instead of reading /etc/vconsole.conf, using localectl, and parsing > the x11 layout/variant would be better? > > localectl status > VC Keymap: us-dvorak-alt-intl > X11 Layout: us > X11 Variant: dvorak-alt-intl > > I think I can do the same in kmscon, or maybe there is a better way than > running an external command, and parsing the output. I will see if I > find something. Something like that, yeah, as you can see from the output on a clean Russian install: test@ibm-p8-kvm-03-guest-02:~$ cat /etc/vconsole.conf KEYMAP="ru" FONT="latarcyrheb-sun16" test@ibm-p8-kvm-03-guest-02:~$ localectl status System Locale: LANG=ru_RU.UTF-8 VC Keymap: ru X11 Layout: us,ru X11 Model: pc105 X11 Variant: , X11 Options: grp:alt_shift_toggle though, er, the variant there looks like a bit odd, not sure if that's a bug in the lookup table code or just an oddity of localectl output or what. Main point, though, is the layout is given as 'us,ru' , which means both us and ru layouts. You need access to the 'us' layout (or some other ASCII-capable layout, but in the real world it seems 'us' is always the layout used) to be able to type ASCII characters; the 'ru' xkb layout can *only* type Cyrillic characters. vconsole (kbd) input is different because only one actual map can be loaded at a time. In that system, switched layouts are handled by effectively stuffing multiple layouts into one map. If you look at the 'ru' kbd layout - https://github.com/legionus/kbd/blob/master/data/keymaps/i386/qwerty/ru.map - you'll see that most letter keys map an ASCII lower-case letter to the bare key, an ASCII upper-case letter to shift+key, a Cyrillic lower-case letter to altgr+key, and a Cyrillic upper-case letter to altgr+shift+key. This doesn't mean you have to hold down altgr permanently if you want to type Russian; the layout also maps shift+control (shift+keycode 29) and altgr+shift+control to "AltGr_Lock", which does exactly what it sounds like, it's like caps lock but for altgr. So shift+control acts like a layout toggle; press it once and you're in "Russian mode", press it again and you're in "ASCII mode". xkb decided to handle this instead by allowing as many layouts as you like to be configured and allowing for mechanisms to switch between the configured layouts, which is much more flexible. But this makes it very awkward to 'map' between xkb and kbd configurations, which is a constant source of weird problems and messy code if you ever find yourself sucked into this particular rabbit hole (for instance, https://bugzilla.redhat.com/show_bug.cgi?id=2121106 was a fun one, check comment #17 for lots of gory details!) One thing that would need to be figured out is whether each of the Wayland-based console implementations actually provides a mechanism to switch between multiple configured xkb layouts. This is something users of switched layouts - it's not just Russian, you can see all of them (at least all the ones we know about...) in https://github.com/systemd/systemd/blob/main/src/locale/kbd-model-map , they're all the ones whose 'xlayout' is two comma-separated layouts - will expect to work. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
