On Wed, Apr 23, 2025 at 04:06:15PM -0700, Adam Williamson wrote: > 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.
"XKB" is a bit overloaded since it refers to a number of things. In the Wayland stack you have 3 components that matter: - compositor which invokes libxkbcommon - libxbkcommon which reads/parses the files provided by xkeyboard-config - xkeyboard-config which provides the actual information but has no computation itself, it's just files sitting on the disk. Once the compositor told libxkbcommon what keymap you wanted (e.g. "us(intl)") it - creates a keymap state - gets a string representation of said keymap to send to the Wayland clients which then (with libxkbcommon's help) recreates a keymap state. That string is readonly so they can only recreate that exact state they got from the compositor. Then both sides pass the key events to the state to get the results so they can do layout-y things (like obtaining keysyms). Note that since it's all controlled by the compositor it is that compositor which needs to provide the hooks to do things differently. This includes things like assigning new layouts, etc. Right now those configurations are all specific to the compositor. In the X stack you have 3 components that matter: - X server which invokes xkbcomp - xkbcomp which reads the files provided by xkeyboard-config - xkeyboard-config which... (see above) Once you told the server which layout you want it forks+exec xkbcomp to do the parsing and dumps out a binary file which is then read back by the server to create the keymap. After that, the server does the same event->update-state->keysym process. The keymap is sent to the client via the X11 XKB protocol and then it's effectively the same event->update-state->keysym process in the client. Layout switches in multi-layouts (which in XKB are just an index changing) are handled by the compositor/X server by sending the new index via the Wayland/X11 protocol and expecting the client to do the right thing. There are a few details missing (notably that users almost always configure via layouts/variants/options, neither of which actually exist in the keymap files, they be constructed by the rules parser) but it's good enough I hope. Anyway, the biggest difference between the two approaches is that the X server (via the X11 XKB protocol extension) has an API you can poke to tell the server to change the keymap (and more) whereas Wayland's keymap bits are all read-onlh only. The rest of the stack is roughly but mostly the same, at least for the purpose of this discussion. > > > > 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. XKB variants can only exist as part of a layout, so splitting them up is not technically correct but historically common. You can have us(dvorak), fr(dvorak), ... but you can't have "dvorak" on its own. The base layout is variant-less so in your case it's simply '',''. If you'd do us(dvorak) this would read as "dvorak," or for the russian version it'd be ",dvorak". In other words, this appears to be a fault of the chosen representation style rather than a bug. > 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 as long as you want as many as 4 :) That limit doesn't need to exist in Wayland but it does in X, so, uhm, dodo sooner! Cheers, Peter > 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
