On 24/04/2025 01:06, 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.
Thanks a lot for the detailed explanation.
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
I've updated the cage+foot script, to use the localectl output instead
of /etc/vconsole.conf.
https://gitlab.com/kdj0c/userspacevt/-/merge_requests/2/diffs
That should handle the model and options too.
For kmscon, using dbus should be easier, I'm adding that to my todo list.
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!)
ok, I didn't know the keymap would be different between fbcon, and
x11/wayland environment. So that's another benefit of switching to
userspace console, to have unified keymap handling.
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.
ok, I will run some tests, to see if this switch works in the userspace
consoles. As they are all using xkb-common, I hope they will behave the
same.
--
Jocelyn
--
_______________________________________________
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
