On Wed, Apr 23, 2025 at 6:26 PM Jocelyn Falempe <jfale...@redhat.com> wrote: > > On 23/04/2025 19:34, Adam Williamson wrote: > > On Wed, 2025-04-23 at 18:17 +0200, Jocelyn Falempe wrote: > >> On 23/04/2025 18:01, Adam Williamson wrote: > >>> On Wed, 2025-04-23 at 11:43 -0400, Neal Gompa wrote: > >>>> On Wed, Apr 23, 2025 at 11:42 AM Adam Williamson > >>>> <adamw...@fedoraproject.org> wrote: > >>>>> > >>>>> On Tue, 2025-04-22 at 11:51 +0200, Jocelyn Falempe wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I've packaged 3 userspace consoles, on my copr repository for Fedora. > >>>>>> They can replace fbcon (The default kernel-based console), have more > >>>>>> features (like scrolling) and are more secure as they run in userspace. > >>>>>> > >>>>>> * Kmscon: https://copr.fedorainfracloud.org/coprs/jfalempe/kmscon/ > >>>>>> * Cage/foot or Gnome-kiosk/Ptyxis: > >>>>>> https://copr.fedorainfracloud.org/coprs/jfalempe/Userspacevt/ > >>>>> > >>>>> Do they use xkb keyboard layouts and configuration? Or kbd? > >>>> > >>>> The Wayland ones will use xkb. kmscon probably still uses kbd. > >>> > >>> then for the love of god can we switch to a wayland one yesterday? :P > >> > >> Kmscon uses xkbcommon, so probably xkb too. > >> > >>> > >>> (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? > > > > >> > >> 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. >
Teaching kmscon to just get the information from locale1 would be ideal. Then it becomes trivially modifiable at runtime with instant effect. -- 真実はいつも一つ!/ Always, there's only one truth! -- _______________________________________________ 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