* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts @ 2020-03-28 13:42 pelzflorian (Florian Pelz) 2020-03-28 19:45 ` Mathieu Othacehe 2020-03-29 15:04 ` Ludovic Courtès 0 siblings, 2 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-03-28 13:42 UTC (permalink / raw) To: 40273 After selecting non-Latin keyboard layouts in the graphical installer, there is no way to input Latin characters again. This means hostname, username, password, the home directory path /home/… cannot be specified in Latin. There either should be a way to switch the keyboard layout later on. For example currently there is neither a place in the GUI to switch the layout nor key combinations or (on a Japanese keyboard) support for the keyboard’s romaji key to switch layouts. Of course typing `loadkeys` is impossible too. Or the keyboard layout should not be switched to non-Latin. For example, when choosing Arabic AZERTY layout, during install the keyboard should be switched to Latin AZERTY layout and not Arabic. Note that choosing non-Latin usernames and passwords appears to have caused problems before, see <https://bugs.gnu.org/37872> (I have not tested it). Similar considerations: Maybe the default keyboard layout for virtual console TTYs and bootloaders should be Latin unless changed explicitly. Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-28 13:42 bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts pelzflorian (Florian Pelz) @ 2020-03-28 19:45 ` Mathieu Othacehe 2020-03-30 10:44 ` pelzflorian (Florian Pelz) 2020-03-29 15:04 ` Ludovic Courtès 1 sibling, 1 reply; 40+ messages in thread From: Mathieu Othacehe @ 2020-03-28 19:45 UTC (permalink / raw) To: 40273 Hello, Maybe we could add a help menu with <F1> key shortcut. From that help menu, one could change the current keyboard layout from any installation step? WDYT? Mathieu ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-28 19:45 ` Mathieu Othacehe @ 2020-03-30 10:44 ` pelzflorian (Florian Pelz) 2020-03-30 11:35 ` Mathieu Othacehe 0 siblings, 1 reply; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-03-30 10:44 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: 40273 On Sat, Mar 28, 2020 at 08:45:05PM +0100, Mathieu Othacehe wrote: > Maybe we could add a help menu with <F1> key shortcut. From that > help menu, one could change the current keyboard layout from any > installation step? > Yes, that is definitely a good place, *but* now that I saw Debian, it would be good to additionally have a key combination. I think switching in an F1 help menu is more discoverable and having both would be good. From what an Arab friend told me, they are used to a key combination (Alt+Shift if I remember correctly, as is Debian’s default; Debian makes the combination configurable). But I cannot figure out how to make loadkeys use a key combination; ckbcomp seems not to produce right results. In QEMU on the compatibility console I ran “sendkey ctrl-alt-f3“. I then tried: guix environment --ad-hoc console-setup #so I can run ckbcomp mkdir -p /usr/share/X11/ cd /usr/share/X11 ln -s $(guix build -S console-setup)/Keyboard/ckb xkb ckbcomp ar, -variant azerty, -option grp:toggle > ~/test loadkeys us #so I can switch back, I hoped, but it does not work loadkeys ~/test But now I can only type Arabic. Maybe it is because of QEMU. I tried changing the keyboard-layout in /etc/config.scm, but then I can no longer type my password. Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-30 10:44 ` pelzflorian (Florian Pelz) @ 2020-03-30 11:35 ` Mathieu Othacehe 2020-03-30 17:11 ` pelzflorian (Florian Pelz) 0 siblings, 1 reply; 40+ messages in thread From: Mathieu Othacehe @ 2020-03-30 11:35 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: 40273 > Yes, that is definitely a good place, *but* now that I saw Debian, it > would be good to additionally have a key combination. I think > switching in an F1 help menu is more discoverable and having both > would be good. OK, noted. > From what an Arab friend told me, they are used to a key combination > (Alt+Shift if I remember correctly, as is Debian’s default; Debian > makes the combination configurable). But I cannot figure out how to > make loadkeys use a key combination; ckbcomp seems not to produce > right results. > > In QEMU on the compatibility console I ran “sendkey ctrl-alt-f3“. I > then tried: > > guix environment --ad-hoc console-setup #so I can run ckbcomp > mkdir -p /usr/share/X11/ > cd /usr/share/X11 > ln -s $(guix build -S console-setup)/Keyboard/ckb xkb > ckbcomp ar, -variant azerty, -option grp:toggle > ~/test > loadkeys us #so I can switch back, I hoped, but it does not work > loadkeys ~/test In the installer, the keyboard layout is handled by KMSCON. It means that running setxkbmap or loadkeys commands won't help. As KMSCON only supports static keyboard layout setting at start time, I had to patch it dirty (see kmscon-runtime-keymap-switch.patch). With this patch, it is possible to write keyboard model, layout and variant to the file pointed by KEYMAP_UPDATE environment variable, and have the keyboard layout updated (see kmscon-update-keymap). Mathieu ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-30 11:35 ` Mathieu Othacehe @ 2020-03-30 17:11 ` pelzflorian (Florian Pelz) 2020-03-30 17:31 ` pelzflorian (Florian Pelz) 2020-03-31 15:35 ` Ludovic Courtès 0 siblings, 2 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-03-30 17:11 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: 40273 [-- Attachment #1: Type: text/plain, Size: 746 bytes --] On Mon, Mar 30, 2020 at 01:35:29PM +0200, Mathieu Othacehe wrote: > In the installer, the keyboard layout is handled by KMSCON. It means > that running setxkbmap or loadkeys commands won't help. As KMSCON only > supports static keyboard layout setting at start time, I had to patch it > dirty (see kmscon-runtime-keymap-switch.patch). With this patch, it is > possible to write keyboard model, layout and variant to the file pointed > by KEYMAP_UPDATE environment variable, and have the keyboard layout > updated (see kmscon-update-keymap). > > Mathieu Thank you for the information. The attached patch to Guix enables Alt+Shift toggling of the layout (it is too hacky, and it is always QWERTY layout!). But it is possible. Regards, Florian [-- Attachment #2: kmscon-toggle-layout.patch --] [-- Type: text/plain, Size: 2180 bytes --] diff --git a/gnu/local.mk b/gnu/local.mk index 26eb8f7b09..6c50d2d352 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -1074,6 +1074,7 @@ dist_patch_DATA = \ %D%/packages/patches/kio-search-smbd-on-PATH.patch \ %D%/packages/patches/kmail-Fix-missing-link-libraries.patch \ %D%/packages/patches/kmod-module-directory.patch \ + %D%/packages/patches/kmscon-test.patch \ %D%/packages/patches/kmscon-runtime-keymap-switch.patch \ %D%/packages/patches/kpackage-allow-external-paths.patch \ %D%/packages/patches/kmplayer-aarch64.patch \ diff --git a/gnu/packages/patches/kmscon-test.patch b/gnu/packages/patches/kmscon-test.patch new file mode 100644 index 0000000000..aeeebe3c09 --- /dev/null +++ b/gnu/packages/patches/kmscon-test.patch @@ -0,0 +1,15 @@ +diff -ur a/src/uterm_input_uxkb.c b/src/uterm_input_uxkb.c +--- a/src/uterm_input_uxkb.c 1970-01-01 01:00:00.000000000 +0100 ++++ b/src/uterm_input_uxkb.c 2020-03-30 18:27:40.880000000 +0200 +@@ -215,7 +215,10 @@ + + llog_info(dev->input, "HANDLER CALLED %s|%s|%s\n", + model, layout, variant); +- uxkb_desc_init(dev->input, model, layout, variant, NULL, NULL); ++ int end_of_layout; ++ for (end_of_layout=0; layout[end_of_layout]; end_of_layout++); ++ memcpy (layout+end_of_layout, (void *)",us", 4); ++ uxkb_desc_init(dev->input, model, layout, variant, "grp:alt_shift_toggle", NULL); + + dev->state = xkb_state_new(dev->input->keymap); + if (!dev->state) { diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm index 9cb004e36a..9af293ab6d 100644 --- a/gnu/packages/terminals.scm +++ b/gnu/packages/terminals.scm @@ -272,7 +272,7 @@ compatibility to existing emulators like xterm, gnome-terminal, konsole, etc.") (base32 "0q62kjsvy2iwy8adfiygx2bfwlh83rphgxbis95ycspqidg9py87")) (patches - (search-patches "kmscon-runtime-keymap-switch.patch")) + (search-patches "kmscon-runtime-keymap-switch.patch" "kmscon-test.patch")) (modules '((guix build utils))) (file-name (git-file-name name version)))) (build-system gnu-build-system) ^ permalink raw reply related [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-30 17:11 ` pelzflorian (Florian Pelz) @ 2020-03-30 17:31 ` pelzflorian (Florian Pelz) 2020-03-31 15:35 ` Ludovic Courtès 1 sibling, 0 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-03-30 17:31 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: 40273 On Mon, Mar 30, 2020 at 07:11:13PM +0200, pelzflorian (Florian Pelz) wrote: > The attached patch to Guix enables > Alt+Shift toggling of the layout (it is too hacky, and it is always > QWERTY layout!). But it is possible. Please someone else decide on the right approach. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-30 17:11 ` pelzflorian (Florian Pelz) 2020-03-30 17:31 ` pelzflorian (Florian Pelz) @ 2020-03-31 15:35 ` Ludovic Courtès 2020-03-31 16:55 ` pelzflorian (Florian Pelz) 1 sibling, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-03-31 15:35 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: 40273 Hi, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis: > On Mon, Mar 30, 2020 at 01:35:29PM +0200, Mathieu Othacehe wrote: >> In the installer, the keyboard layout is handled by KMSCON. It means >> that running setxkbmap or loadkeys commands won't help. As KMSCON only >> supports static keyboard layout setting at start time, I had to patch it >> dirty (see kmscon-runtime-keymap-switch.patch). With this patch, it is >> possible to write keyboard model, layout and variant to the file pointed >> by KEYMAP_UPDATE environment variable, and have the keyboard layout >> updated (see kmscon-update-keymap). >> >> Mathieu > > Thank you for the information. The attached patch to Guix enables > Alt+Shift toggling of the layout (it is too hacky, and it is always > QWERTY layout!). But it is possible. I think we can have both Alt-Shift and what Mathieu implemented, no? However, note that the installed system won’t have Alt-Shift support, and perhaps that is a bigger concern. OTOH, we’re just using the standard XKB layouts, so if they don’t provide Alt-Shift, well, perhaps that’s because this is the way it’s got to be? > ++ int end_of_layout; > ++ for (end_of_layout=0; layout[end_of_layout]; end_of_layout++); > ++ memcpy (layout+end_of_layout, (void *)",us", 4); I think that could be: layout = strcat (layout, ",us"); Provided ‘layout’ points to a large-enough array. > ++ uxkb_desc_init(dev->input, model, layout, variant, "grp:alt_shift_toggle", NULL); Is “grp:alt_shift_toggle” guaranteed to be available, no what what ‘layout’ is? Also, that means Alt-Shift is enabled for all layouts, not just the non-Latin layouts, right? Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-31 15:35 ` Ludovic Courtès @ 2020-03-31 16:55 ` pelzflorian (Florian Pelz) 2020-04-01 20:33 ` Bengt Richter 2020-04-02 9:45 ` Ludovic Courtès 0 siblings, 2 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-03-31 16:55 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 On Tue, Mar 31, 2020 at 05:35:41PM +0200, Ludovic Courtès wrote: > I think we can have both Alt-Shift and what Mathieu implemented, no? > Yes, both would be best, what Mathieu implemented is more discoverable. > However, note that the installed system won’t have Alt-Shift support, > and perhaps that is a bigger concern. Yes. guix build -S console-setup sudo mkdir -p /usr/share/X11 cd /usr/share/X11 sudo ln -s /gnu/store/fabcbhjh4g5fmm39fmkjjhiplqwrg0n8-console-setup-1.194-checkout/Keyboard/ckb xkb ckbcomp ar,fr -variant azerty, -option grp:alt_shift_toggle > ~/test sudo loadkeys ~/test works, but I have no idea how to turn that into a keyboard-layout. I tried setting in /etc/config.scm (keyboard-layout (keyboard-layout "ar,fr" "azerty" #:options '("grp:alt_shift_toggle"))) but it threw an error. > OTOH, we’re just using the standard XKB layouts, so if they don’t > provide Alt-Shift, well, perhaps that’s because this is the way it’s got > to be? I did not know back then, but it does work. In dconf-editor, I can set org.gnome.desktop.input-sources to ['grp:alt_shift_toggle']. It switches between all configured layouts in GNOME. > Is “grp:alt_shift_toggle” guaranteed to be available, no what what > ‘layout’ is? > > Also, that means Alt-Shift is enabled for all layouts, not just the > non-Latin layouts, right? Yes, with the patch I can toggle any layout to US layout and back. I believe we would need a map from each layout to whether it should be QWERTY, AZERTY, QWERTZ … Or we would just use QWERTY. What do you think is the right path forward? Thank you. Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-31 16:55 ` pelzflorian (Florian Pelz) @ 2020-04-01 20:33 ` Bengt Richter 2020-04-02 6:24 ` pelzflorian (Florian Pelz) 2020-04-02 9:45 ` Ludovic Courtès 1 sibling, 1 reply; 40+ messages in thread From: Bengt Richter @ 2020-04-01 20:33 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: 40273 Hi Florian, On +2020-03-31 18:55:59 +0200, pelzflorian (Florian Pelz) wrote: > On Tue, Mar 31, 2020 at 05:35:41PM +0200, Ludovic Courtès wrote: > > I think we can have both Alt-Shift and what Mathieu implemented, no? > > > > Yes, both would be best, what Mathieu implemented is more > discoverable. > > > However, note that the installed system won’t have Alt-Shift support, > > and perhaps that is a bigger concern. > > Yes. > > guix build -S console-setup > sudo mkdir -p /usr/share/X11 > cd /usr/share/X11 > sudo ln -s /gnu/store/fabcbhjh4g5fmm39fmkjjhiplqwrg0n8-console-setup-1.194-checkout/Keyboard/ckb xkb > ckbcomp ar,fr -variant azerty, -option grp:alt_shift_toggle > ~/test > sudo loadkeys ~/test > > works, but I have no idea how to turn that into a keyboard-layout. > I tried setting in /etc/config.scm > > (keyboard-layout > (keyboard-layout "ar,fr" "azerty" #:options '("grp:alt_shift_toggle"))) > > but it threw an error. > > > OTOH, we’re just using the standard XKB layouts, so if they don’t > > provide Alt-Shift, well, perhaps that’s because this is the way it’s got > > to be? > > I did not know back then, but it does work. In dconf-editor, I can > set org.gnome.desktop.input-sources to ['grp:alt_shift_toggle']. It > switches between all configured layouts in GNOME. > > > Is “grp:alt_shift_toggle” guaranteed to be available, no what what > > ‘layout’ is? > > > > Also, that means Alt-Shift is enabled for all layouts, not just the > > non-Latin layouts, right? > > Yes, with the patch I can toggle any layout to US layout and back. > Have you looked at man vconsole.conf http://man7.org/linux/man-pages/man5/vconsole.conf.5.html Could this be helpful? https://unix.stackexchange.com/q/57085 Also this has more extensive info on creating/modifying keymaps and getting systemd to get them going: https://wiki.archlinux.org/index.php/Linux_console/Keyboard_configuration I don't know if this is useful, but seems like you can affect things early in the boot sequence (from the man page): --8<---------------cut here---------------start------------->8--- Note that the kernel command line options vconsole.keymap=, vconsole.keymap_toggle=, vconsole.font=, vconsole.font_map=, console.font_unimap= may be used to override the console settings at boot. --8<---------------cut here---------------end--------------->8--- > I believe we would need a map from each layout to whether it should be > QWERTY, AZERTY, QWERTZ … Or we would just use QWERTY. > > What do you think is the right path forward? Do the right thing :) > > Thank you. > > Regards, > Florian > -- Regards, Bengt Richter ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-01 20:33 ` Bengt Richter @ 2020-04-02 6:24 ` pelzflorian (Florian Pelz) 0 siblings, 0 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-04-02 6:24 UTC (permalink / raw) To: Bengt Richter; +Cc: 40273 On Wed, Apr 01, 2020 at 10:33:18PM +0200, Bengt Richter wrote: > I don't know if this is useful, but seems like you can affect things > early in the boot sequence (from the man page): > --8<---------------cut here---------------start------------->8--- > Note that the kernel command line options vconsole.keymap=, > vconsole.keymap_toggle=, vconsole.font=, vconsole.font_map=, > console.font_unimap= may be used to override the console settings at > boot. > --8<---------------cut here---------------end--------------->8--- Thank you for the suggestion. With vconsole.keymap_toggle in QEMU I do not know what key to press in order to toggle. Right Alt key or Alt+Shift does not work, so I believe the vconsole kernel parameter is not used without installing the 90-vconsole.rules udev rules file from systemd. The rules file runs a program systemd-vconsole-setup it seems which uses KDFONTOP ioctl: https://github.com/systemd/systemd/blob/master/src/vconsole/vconsole-setup.c I would prefer a toggle keymap that is set to "us" or "fr" or whatever at runtime. I believe this would be easiest by patching kmscon to not only accept a layout (like now) but also a (not necessarily hard-coded) option grp:alt_shift_toggle or grp:toggle (for right Alt key, if the keyboard has one) or similar. But "us" QWERTY as a fixed toggle keymap would help too of course. > > What do you think is the right path forward? > Do the right thing > :) I hope someone who knows the codebase and what to put where made a patch. I should have said so. Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-31 16:55 ` pelzflorian (Florian Pelz) 2020-04-01 20:33 ` Bengt Richter @ 2020-04-02 9:45 ` Ludovic Courtès 2020-04-03 0:38 ` pelzflorian (Florian Pelz) 1 sibling, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-04-02 9:45 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: 40273 [-- Attachment #1: Type: text/plain, Size: 925 bytes --] Hello Florian, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis: > works, but I have no idea how to turn that into a keyboard-layout. > I tried setting in /etc/config.scm > > (keyboard-layout > (keyboard-layout "ar,fr" "azerty" #:options '("grp:alt_shift_toggle"))) > > but it threw an error. The attached patch fixes that. I’ve confirmed that it works as intended in Xorg and in the console (I’m not sure it works in GDM, but it definitely works in an xterm in ratpoison, for instance.) I was wondering whether to push the patch as-is or to require people to write: (keyboard-layout '("ar" "fr") …) instead. Maybe it’s OK to leave the comma here. However, I noticed that this doesn’t work in GRUB. Actually, even (keyboard-layout "fr") doesn’t work in GRUB (at the command line after the boot menu), which seems like a regression. Thanks, Ludo’. [-- Attachment #2: Type: text/x-patch, Size: 1753 bytes --] diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm index 28e6cb1f5f..190b717163 100644 --- a/gnu/bootloader/grub.scm +++ b/gnu/bootloader/grub.scm @@ -240,7 +240,11 @@ the 'share/X11/xkb/symbols/' directory of 'xkeyboard-config'." "-i" #+(keyboard-layout->console-keymap layout) "-o" #$output)))) - (computed-file (string-append "grub-keymap." (keyboard-layout-name layout)) + (computed-file (string-append "grub-keymap." + (string-map (match-lambda + (#\, #\-) + (chr chr)) + (keyboard-layout-name layout))) builder)) (define (grub-setup-io config) diff --git a/gnu/system/keyboard.scm b/gnu/system/keyboard.scm index cd3ab37b27..5bd13a44be 100644 --- a/gnu/system/keyboard.scm +++ b/gnu/system/keyboard.scm @@ -1,5 +1,5 @@ ;;; GNU Guix --- Functional package management for GNU -;;; Copyright © 2019 Ludovic Courtès <ludo@gnu.org> +;;; Copyright © 2019, 2020 Ludovic Courtès <ludo@gnu.org> ;;; ;;; This file is part of GNU Guix. ;;; @@ -94,5 +94,8 @@ Layout information is taken from the XKEYBOARD-CONFIG package." #$(keyboard-layout-name layout)))))) (computed-file (string-append "console-keymap." - (keyboard-layout-name layout)) + (string-map (match-lambda + (#\, #\-) + (chr chr)) + (keyboard-layout-name layout))) build)) ^ permalink raw reply related [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-02 9:45 ` Ludovic Courtès @ 2020-04-03 0:38 ` pelzflorian (Florian Pelz) 2020-04-03 1:11 ` pelzflorian (Florian Pelz) ` (3 more replies) 0 siblings, 4 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-04-03 0:38 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 On Thu, Apr 02, 2020 at 11:45:01AM +0200, Ludovic Courtès wrote: > The attached patch fixes that. I’ve confirmed that it works as intended > in Xorg and in the console Thank you, it works fine, even for entering the LUKS passphrase after GRUB in the Linux kernel. Only GRUB uses U.S. QWERTY layout. > (I’m not sure it works in GDM, but it > definitely works in an xterm in ratpoison, for instance.) GDM retains my U.S. English layout even after herd stop xorg-server and deleting all files in /var/lib/gdm. Deleting all files also made my fonts different in gnome-terminal, Icecat, Emacs, also gnome-initial-setup got run again, but these issues are unrelated to this bug and do not happen if one does not “sudo rm -rf /var/lib/gdm/.*”. > I was wondering whether to push the patch as-is or to require people to > write: > > (keyboard-layout '("ar" "fr") …) > > instead. Maybe it’s OK to leave the comma here. Lists seem more consistent with the Scheme syntax. > > However, I noticed that this doesn’t work in GRUB. Actually, even > (keyboard-layout "fr") doesn’t work in GRUB (at the command line after > the boot menu), which seems like a regression. I suppose on GRUB using at_keyboard it worked in the past? For me there’s no regression because keyboard layouts never worked (using usb keyboard rather than at keyboard), see <https://issues.guix.info/issue/35585#9>. Back then I was told to open a bug at GRUB, which I have not done. There are other old bugs on keyboard layouts and bugs on USB keyboards among the GRUB bugs at Savannah though. I find an e-mail to bug-grub concerning the same issue <https://lists.gnu.org/archive/html/bug-grub/2017-10/msg00003.html>, but no bug at Savannah. I will not open a bug I suppose, also the GRUB manual says many keymaps don’t work well. https://www.gnu.org/software/grub/manual/grub/html_node/Internationalisation.html#Input-terminal It says “Own keyboard implementations (at_keyboard and usb_keyboard) supports any key but work on one-char-per-keystroke. So no dead keys or advanced input method. Also there is no keymap change hotkey. In practice it makes difficult to enter any text using non-Latin alphabet. Moreover all current input consumers are limited to ASCII.” f5961dd5854cec1ed9a41365836d63aa15256642 for usb keyboard was a bad commit (passphrase input was QWERTY, back then usb keyboard did not work at all in GRUB menu). Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-03 0:38 ` pelzflorian (Florian Pelz) @ 2020-04-03 1:11 ` pelzflorian (Florian Pelz) 2020-04-03 13:31 ` pelzflorian (Florian Pelz) ` (2 subsequent siblings) 3 siblings, 0 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-04-03 1:11 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 On Fri, Apr 03, 2020 at 02:38:16AM +0200, pelzflorian (Florian Pelz) wrote: > For me there’s no regression because keyboard layouts never worked Maybe there is a regression for at_keyboard users. For usb_keyboard: I believe it would be easier to ignore the wrong keyboard layout for the GRUB command-line and to resolve the layout issue for the passphrase by not requiring one. That is (as a default) installing GRUB on the unencrypted EFI System Partition. AFAIK this is currently not possible. It would require copying all references of grub.cfg to the EFI System Partition instead of the encrypted Store. On non-EFI systems, this would make it necessary to have a separate boot partition when using encryption. Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-03 0:38 ` pelzflorian (Florian Pelz) 2020-04-03 1:11 ` pelzflorian (Florian Pelz) @ 2020-04-03 13:31 ` pelzflorian (Florian Pelz) 2020-04-03 13:59 ` pelzflorian (Florian Pelz) 2020-04-03 15:20 ` Ludovic Courtès 3 siblings, 0 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-04-03 13:31 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 On Fri, Apr 03, 2020 at 02:38:16AM +0200, pelzflorian (Florian Pelz) wrote: > Deleting all files also made > my fonts different Different fonts was due to an unrelated mistake of mine; I accidently removed the font-dejavu package from my config.scm. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-03 0:38 ` pelzflorian (Florian Pelz) 2020-04-03 1:11 ` pelzflorian (Florian Pelz) 2020-04-03 13:31 ` pelzflorian (Florian Pelz) @ 2020-04-03 13:59 ` pelzflorian (Florian Pelz) 2020-04-03 15:20 ` Ludovic Courtès 3 siblings, 0 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-04-03 13:59 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 On Fri, Apr 03, 2020 at 02:38:16AM +0200, pelzflorian (Florian Pelz) wrote: > GDM retains my U.S. English layout even after herd stop xorg-server > and deleting all files in /var/lib/gdm. This too was my mistake for omitting keyboard-layout settings in set-xorg-configuration. All is well. Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-03 0:38 ` pelzflorian (Florian Pelz) ` (2 preceding siblings ...) 2020-04-03 13:59 ` pelzflorian (Florian Pelz) @ 2020-04-03 15:20 ` Ludovic Courtès 2020-04-03 15:56 ` pelzflorian (Florian Pelz) 3 siblings, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-04-03 15:20 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: 40273 Hi, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis: > On Thu, Apr 02, 2020 at 11:45:01AM +0200, Ludovic Courtès wrote: >> The attached patch fixes that. I’ve confirmed that it works as intended >> in Xorg and in the console > > Thank you, it works fine, even for entering the LUKS passphrase after > GRUB in the Linux kernel. Only GRUB uses U.S. QWERTY layout. OK. >> (I’m not sure it works in GDM, but it >> definitely works in an xterm in ratpoison, for instance.) > > GDM retains my U.S. English layout even after herd stop xorg-server That’s a regression. Localed was added exactly one year ago to fix this problem in commit 607fcc75404e2b1fc74affcf372b4a6a789ac55e. I’ve spent a couple of hours investigating and I don’t know why it doesn’t work, especially since it works fine once logged in in GNOME (it’s the same code, GNOME Shell). >> I was wondering whether to push the patch as-is or to require people to >> write: >> >> (keyboard-layout '("ar" "fr") …) >> >> instead. Maybe it’s OK to leave the comma here. > > Lists seem more consistent with the Scheme syntax. OTOH, it has the potential of breaking things here and there; also, I’d rather stay close to XKB. If that’s fine with you, I propose applying that patch and adding a sentence in “Keyboard Layout” to document that. >> However, I noticed that this doesn’t work in GRUB. Actually, even >> (keyboard-layout "fr") doesn’t work in GRUB (at the command line after >> the boot menu), which seems like a regression. > > I suppose on GRUB using at_keyboard it worked in the past? > > For me there’s no regression because keyboard layouts never worked > (using usb keyboard rather than at keyboard), see > <https://issues.guix.info/issue/35585#9>. Damn it, so it’s this ‘terminal_input’ directive that broke it? > f5961dd5854cec1ed9a41365836d63aa15256642 for usb keyboard was a bad > commit (passphrase input was QWERTY, back then usb keyboard did not > work at all in GRUB menu). That has always been a problem, see <https://issues.guix.gnu.org/issue/39288>. Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-03 15:20 ` Ludovic Courtès @ 2020-04-03 15:56 ` pelzflorian (Florian Pelz) 2020-04-05 14:03 ` Ludovic Courtès 0 siblings, 1 reply; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-04-03 15:56 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 On Fri, Apr 03, 2020 at 05:20:23PM +0200, Ludovic Courtès wrote: > > GDM retains my U.S. English layout even after herd stop xorg-server > > That’s a regression. Localed was added exactly one year ago to fix this > problem in commit 607fcc75404e2b1fc74affcf372b4a6a789ac55e. I’ve spent > a couple of hours investigating and I don’t know why it doesn’t work, > especially since it works fine once logged in in GNOME (it’s the same > code, GNOME Shell). Sorry! It is entirely my fault. I had not known that if I don’t put a keyboard-layout field in set-xorg-configuration, I always get U.S. layout. > OTOH, it has the potential of breaking things here and there; also, I’d > rather stay close to XKB. > > If that’s fine with you, I propose applying that patch and adding a > sentence in “Keyboard Layout” to document that. I agree that staying close to XKB is a good reason. Thank you for all your work!! > > >> However, I noticed that this doesn’t work in GRUB. Actually, even > >> (keyboard-layout "fr") doesn’t work in GRUB (at the command line after > >> the boot menu), which seems like a regression. > > > > I suppose on GRUB using at_keyboard it worked in the past? > > > > For me there’s no regression because keyboard layouts never worked > > (using usb keyboard rather than at keyboard), see > > <https://issues.guix.info/issue/35585#9>. > > Damn it, so it’s this ‘terminal_input’ directive that broke it? I can only use the usb_keyboard input terminal and cannot use at_keyboard with my Macbook. Not specifying a terminal_input was the right resolution for that bug, because now it uses usb_keyboard automatically. It’s just that usb_keyboard cannot use keyboard layouts, it seems, and overall GRUB does not support all features needed from keyboard layouts according to the manual. Not encrypting grub’s file system seems easier. Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-03 15:56 ` pelzflorian (Florian Pelz) @ 2020-04-05 14:03 ` Ludovic Courtès 2020-04-05 20:02 ` pelzflorian (Florian Pelz) 0 siblings, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-04-05 14:03 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: 40273 Hi, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis: > On Fri, Apr 03, 2020 at 05:20:23PM +0200, Ludovic Courtès wrote: >> > GDM retains my U.S. English layout even after herd stop xorg-server >> >> That’s a regression. Localed was added exactly one year ago to fix this >> problem in commit 607fcc75404e2b1fc74affcf372b4a6a789ac55e. I’ve spent >> a couple of hours investigating and I don’t know why it doesn’t work, >> especially since it works fine once logged in in GNOME (it’s the same >> code, GNOME Shell). > > Sorry! It is entirely my fault. I had not known that if I don’t put > a keyboard-layout field in set-xorg-configuration, I always get > U.S. layout. Hmm, on master, if I change desktop.tmpl to use the “fr” layout, I get a French keyboard layout in the console, but not in GDM. (In a fresh VM built with ‘guix system vm’.) Can you confirm you see this problem? Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-05 14:03 ` Ludovic Courtès @ 2020-04-05 20:02 ` pelzflorian (Florian Pelz) 2020-04-05 21:26 ` Ludovic Courtès 0 siblings, 1 reply; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-04-05 20:02 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 On Sun, Apr 05, 2020 at 04:03:54PM +0200, Ludovic Courtès wrote: > Can you confirm you see this problem? In my actual system configuration I have French layout in GDM and console with today’s git master. No problem. I changed: diff --git a/config.scm b/config.scm index 4db5560..1cf1578 100644 --- a/config.scm +++ b/config.scm @@ -29,7 +29,8 @@ (timezone "Europe/Berlin") (locale "tr_TR.utf8") (keyboard-layout - (keyboard-layout "us" "altgr-intl")) + (keyboard-layout "fr")) +;; (keyboard-layout "us" "altgr-intl")) (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) @@ -177,6 +178,7 @@ Options +Indexes")))))) ,gnome-online-accounts))))))) (set-xorg-configuration (xorg-configuration + (keyboard-layout keyboard-layout) (modules (list ;;xf86-video-vesa xf86-video-fbdev In QEMU guix system vm, I cannot get GDM to display more than a mouse pointer no matter the graphics options I try (-vga std or cirrus or nomodeset+uvesafb). This is an unrelated bug, probably not Guix’ fault, though I had not tried GDM in QEMU before. I wanted to try guix system vm-image (expecting another GDM failure), but after many hours building the vm-image failed because I had misconfigured the bootloader EFI file-system. Regards, Florian ^ permalink raw reply related [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-05 20:02 ` pelzflorian (Florian Pelz) @ 2020-04-05 21:26 ` Ludovic Courtès 0 siblings, 0 replies; 40+ messages in thread From: Ludovic Courtès @ 2020-04-05 21:26 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: 40273 Hi, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis: > On Sun, Apr 05, 2020 at 04:03:54PM +0200, Ludovic Courtès wrote: >> Can you confirm you see this problem? > > In my actual system configuration I have French layout in GDM and > console with today’s git master. No problem. I changed: Nevermind, I found out what the problem was: https://issues.guix.gnu.org/issue/40456 :-/ > In QEMU guix system vm, I cannot get GDM to display more than a mouse > pointer no matter the graphics options I try (-vga std or cirrus or > nomodeset+uvesafb). This is an unrelated bug, probably not Guix’ > fault, though I had not tried GDM in QEMU before. I wanted to try > guix system vm-image (expecting another GDM failure), but after many > hours building the vm-image failed because I had misconfigured the > bootloader EFI file-system. Weird. ‘guix system vm’ works rather quickly for me and it can display GDM just fine. Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-28 13:42 bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts pelzflorian (Florian Pelz) 2020-03-28 19:45 ` Mathieu Othacehe @ 2020-03-29 15:04 ` Ludovic Courtès 2020-03-29 17:16 ` pelzflorian (Florian Pelz) 1 sibling, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-03-29 15:04 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: 40273 Hi Florian, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis: > After selecting non-Latin keyboard layouts in the graphical installer, > there is no way to input Latin characters again. This means hostname, > username, password, the home directory path /home/… cannot be > specified in Latin. > > There either should be a way to switch the keyboard layout later on. > For example currently there is neither a place in the GUI to switch > the layout nor key combinations or (on a Japanese keyboard) support > for the keyboard’s romaji key to switch layouts. Of course typing > `loadkeys` is impossible too. > > Or the keyboard layout should not be switched to non-Latin. For > example, when choosing Arabic AZERTY layout, during install the > keyboard should be switched to Latin AZERTY layout and not Arabic. How do other distros handle it? Is there a hot key to switch back to a Latin layout? If so, which one? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-29 15:04 ` Ludovic Courtès @ 2020-03-29 17:16 ` pelzflorian (Florian Pelz) 2020-03-29 17:53 ` Mathieu Othacehe 0 siblings, 1 reply; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-03-29 17:16 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 On Sun, Mar 29, 2020 at 05:04:11PM +0200, Ludovic Courtès wrote: > How do other distros handle it? Is there a hot key to switch back to a > Latin layout? If so, which one? I test the Newt-based Debian 10 installer via QEMU. When I select English language with Arabic keymap, I can choose a key combination for switching the layout, Alt+Shift by default. But I cannot choose between AZERTY and QWERTY, I always get QWERTY. Searching the Web for the displayed string for choosing the layout reveals it is part of console-setup and contained in $(guix build -S console-setup)/debian/keyboard-configuration.templates I find command suggestions like ckbcomp -layout cs,cs -variant latin, -option grp:rwin_toggle,lv3:ralt_switch,grp_led:scroll as given in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513269>. Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-29 17:16 ` pelzflorian (Florian Pelz) @ 2020-03-29 17:53 ` Mathieu Othacehe 2020-03-30 10:39 ` Mathieu Othacehe 2020-03-31 15:28 ` Ludovic Courtès 0 siblings, 2 replies; 40+ messages in thread From: Mathieu Othacehe @ 2020-03-29 17:53 UTC (permalink / raw) To: 40273 Hey, > I test the Newt-based Debian 10 installer via QEMU. When I select > English language with Arabic keymap, I can choose a key combination > for switching the layout, Alt+Shift by default. But I cannot choose > between AZERTY and QWERTY, I always get QWERTY. Defining such a combination could be an option too. I tried to implement the mechanism I proposed, but had multiple problems: * Shepherd is using /dev/console as an output and some messages are polluting the help line displayed at the bottom of the screen. I'm not sure how to solve it. Shepherd could poll /dev/log so that once syslog is available it stops using /dev/console. * Guile-newt functions "newt-set-help-callback" and "add-component-callback" seem to be tripping over each other and I'm having a hard time trying to understand why. Regardless of this keyboard layout issue, having a help menu for the installer could be useful to display the shortcuts for instance. Thanks, Mathieu ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-29 17:53 ` Mathieu Othacehe @ 2020-03-30 10:39 ` Mathieu Othacehe 2020-03-30 12:39 ` pelzflorian (Florian Pelz) 2020-03-31 15:29 ` Ludovic Courtès 2020-03-31 15:28 ` Ludovic Courtès 1 sibling, 2 replies; 40+ messages in thread From: Mathieu Othacehe @ 2020-03-30 10:39 UTC (permalink / raw) To: 40273 Hey, > * Guile-newt functions "newt-set-help-callback" and > "add-component-callback" seem to be tripping over each other and I'm > having a hard time trying to understand why. Ok I found out why, it was the GC that was collecting the callback pointers. I fixed it in Guile-newt. Now I pushed a 'wip-installer-help' branch that implement this mechanism. I'm now able to switch the installer keyboard layout from any step. WDYT? Mathieu ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-30 10:39 ` Mathieu Othacehe @ 2020-03-30 12:39 ` pelzflorian (Florian Pelz) 2020-03-31 15:29 ` Ludovic Courtès 1 sibling, 0 replies; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-03-30 12:39 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: 40273 On Mon, Mar 30, 2020 at 12:39:50PM +0200, Mathieu Othacehe wrote: > Now I pushed a 'wip-installer-help' branch that implement this > mechanism. I'm now able to switch the installer keyboard layout from any > step. > > WDYT? I like it. The switching also does not affect the generated config.scm. Thank you for all your work. Without being able to use a key combination, I ended up editing the config.scm with an Arabic layout though and cannot exit nano. Key combinations are needed in addition, I suppose. :) Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-30 10:39 ` Mathieu Othacehe 2020-03-30 12:39 ` pelzflorian (Florian Pelz) @ 2020-03-31 15:29 ` Ludovic Courtès 2020-04-01 12:49 ` Mathieu Othacehe 1 sibling, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-03-31 15:29 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: 40273 Hi, Mathieu Othacehe <m.othacehe@gmail.com> skribis: >> * Guile-newt functions "newt-set-help-callback" and >> "add-component-callback" seem to be tripping over each other and I'm >> having a hard time trying to understand why. > > Ok I found out why, it was the GC that was collecting the callback > pointers. I fixed it in Guile-newt. Ouch. Are there possible other such issues lurking? > Now I pushed a 'wip-installer-help' branch that implement this > mechanism. I'm now able to switch the installer keyboard layout from any > step. Woohoo, awesome! Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-31 15:29 ` Ludovic Courtès @ 2020-04-01 12:49 ` Mathieu Othacehe 0 siblings, 0 replies; 40+ messages in thread From: Mathieu Othacehe @ 2020-04-01 12:49 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 Hello Ludo, > Ouch. Are there possible other such issues lurking? The problem occurs when using `procedure->pointer' and passing the returned pointer to a C library that stores it globally. Because, in that case the pointer can be collected from the Guile side and used later-on from the C side. I fixed the two problematic patterns in Guile-Newt. Guile-Git seems to be safe, but there might be an issue with Guile-Parted in `exception-set-handler' method. I will investigate it. > >> Now I pushed a 'wip-installer-help' branch that implement this >> mechanism. I'm now able to switch the installer keyboard layout from any >> step. > > Woohoo, awesome! Thanks :) Mathieu ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-29 17:53 ` Mathieu Othacehe 2020-03-30 10:39 ` Mathieu Othacehe @ 2020-03-31 15:28 ` Ludovic Courtès 2020-04-01 12:52 ` Mathieu Othacehe 1 sibling, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-03-31 15:28 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: 40273 Hi! Mathieu Othacehe <m.othacehe@gmail.com> skribis: > * Shepherd is using /dev/console as an output and some messages are > polluting the help line displayed at the bottom of the screen. I'm not > sure how to solve it. > > Shepherd could poll /dev/log so that once syslog is available it stops > using /dev/console. That’s exactly what it does, see (shepherd comm). Perhaps we just need to have the installer service depend on ‘syslogd’, at which point nothing goes to /dev/console? Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-03-31 15:28 ` Ludovic Courtès @ 2020-04-01 12:52 ` Mathieu Othacehe 2020-04-02 10:25 ` Ludovic Courtès 0 siblings, 1 reply; 40+ messages in thread From: Mathieu Othacehe @ 2020-04-01 12:52 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 Hey, > That’s exactly what it does, see (shepherd comm). > > Perhaps we just need to have the installer service depend on ‘syslogd’, > at which point nothing goes to /dev/console? Heh, I read it too fast, sorry :) The issue was in fact that we are calling `start-service' and `stop-service' from `apply-locale' in (gnu installer), and printing shepherd messages to shepherd-message-port which is stderr by default. Fixed on wip-installer-help. Thanks, Mathieu ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-01 12:52 ` Mathieu Othacehe @ 2020-04-02 10:25 ` Ludovic Courtès 2020-04-02 11:40 ` Mathieu Othacehe 2020-04-02 23:27 ` Bengt Richter 0 siblings, 2 replies; 40+ messages in thread From: Ludovic Courtès @ 2020-04-02 10:25 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: 40273 Hi, Mathieu Othacehe <m.othacehe@gmail.com> skribis: >> That’s exactly what it does, see (shepherd comm). >> >> Perhaps we just need to have the installer service depend on ‘syslogd’, >> at which point nothing goes to /dev/console? > > Heh, I read it too fast, sorry :) The issue was in fact that we are > calling `start-service' and `stop-service' from `apply-locale' in (gnu > installer), and printing shepherd messages to shepherd-message-port > which is stderr by default. > > Fixed on wip-installer-help. Awesome. Do you think that branch is ready for a merge? Or did you want to further discuss some of the changes? Florian seemed to agree that it’s a good thing. Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-02 10:25 ` Ludovic Courtès @ 2020-04-02 11:40 ` Mathieu Othacehe 2020-04-06 7:52 ` Ludovic Courtès 2020-04-02 23:27 ` Bengt Richter 1 sibling, 1 reply; 40+ messages in thread From: Mathieu Othacehe @ 2020-04-02 11:40 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 Hello, > Do you think that branch is ready for a merge? Or did you want to > further discuss some of the changes? Florian seemed to agree that it’s > a good thing. Yes, for me it's ready. If you are ok I can check that our new fancy tests are still passing and merge it :) Now, there are other locale related issues we may want to address before the release: * The keyboard layout issue in Grub console you reported here[1]. * The keyboard layout issue during hard drive decryption in Grub[2]. I had a quick look to the second one and using `grub-mkstandalone' seems to be the right move but it would then require extensive testing on real hardware. Mathieu [1]: https://lists.gnu.org/archive/html/bug-guix/2020-04/msg00024.html [2]: https://lists.gnu.org/archive/html/bug-guix/2020-01/msg00350.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-02 11:40 ` Mathieu Othacehe @ 2020-04-06 7:52 ` Ludovic Courtès 2020-04-06 13:14 ` Mathieu Othacehe 0 siblings, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-04-06 7:52 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: 40273 Hi Mathieu, Mathieu Othacehe <m.othacehe@gmail.com> skribis: >> Do you think that branch is ready for a merge? Or did you want to >> further discuss some of the changes? Florian seemed to agree that it’s >> a good thing. > > Yes, for me it's ready. If you are ok I can check that our new fancy > tests are still passing and merge it :) Yes please! (BTW, sorry for the latency when replying; if you want, please do chime in on #guix on IRC.) > Now, there are other locale related issues we may want to address before > the release: > > * The keyboard layout issue in Grub console you reported here[1]. > * The keyboard layout issue during hard drive decryption in Grub[2]. > > I had a quick look to the second one and using `grub-mkstandalone' seems > to be the right move but it would then require extensive testing on real > hardware. Yeah. If the change ends up looking risky, perhaps we should postpone it? I would really like us to release this week. Thank you! Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-06 7:52 ` Ludovic Courtès @ 2020-04-06 13:14 ` Mathieu Othacehe 2020-04-07 9:49 ` Ludovic Courtès 0 siblings, 1 reply; 40+ messages in thread From: Mathieu Othacehe @ 2020-04-06 13:14 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273, 40273-done Hey, > Yes please! (BTW, sorry for the latency when replying; if you want, > please do chime in on #guix on IRC.) Merged! Heh, I know you are already quite busy :p The installer tests are really a nice addition. Being able to test it running: --8<---------------cut here---------------start------------->8--- make check-system TESTS="gui-installed-os gui-installed-os-encrypted gui-installed-desktop-os-encrypted" --8<---------------cut here---------------end--------------->8--- is much more convenient than by hand. Thanks for your work on that topic. > Yeah. If the change ends up looking risky, perhaps we should postpone > it? I would really like us to release this week. Seems fair. Florian, I'm closing the issue here :) Mathieu ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-06 13:14 ` Mathieu Othacehe @ 2020-04-07 9:49 ` Ludovic Courtès 2020-04-07 17:14 ` Mathieu Othacehe 0 siblings, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-04-07 9:49 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: 40273, 40273-done Hi! Mathieu Othacehe <m.othacehe@gmail.com> skribis: >> Yes please! (BTW, sorry for the latency when replying; if you want, >> please do chime in on #guix on IRC.) > > Merged! Heh, I know you are already quite busy :p > > The installer tests are really a nice addition. Being able to test it > running: > > make check-system TESTS="gui-installed-os gui-installed-os-encrypted gui-installed-desktop-os-encrypted" > > is much more convenient than by hand. Thanks for your work on that > topic. Heh, thanks. Glad we have an easy way to switch layouts in the installer! >> Yeah. If the change ends up looking risky, perhaps we should postpone >> it? I would really like us to release this week. > > Seems fair. > > Florian, I'm closing the issue here :) Ideally we’d also offer a way to choose multiple layouts in the installer, so that one can end up with: (keyboard-layout "ar,us" #:options '("grp:alt_shift_toggle")) Although that’s mostly useful for the console as GDM and GNOME should be able to do the right thing. Anyway, we can discuss it in a separate issue. Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-07 9:49 ` Ludovic Courtès @ 2020-04-07 17:14 ` Mathieu Othacehe 0 siblings, 0 replies; 40+ messages in thread From: Mathieu Othacehe @ 2020-04-07 17:14 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273, 40273-done Hey, > Ideally we’d also offer a way to choose multiple layouts in the > installer, so that one can end up with: > > (keyboard-layout "ar,us" #:options '("grp:alt_shift_toggle")) > > Although that’s mostly useful for the console as GDM and GNOME should be > able to do the right thing. > > Anyway, we can discuss it in a separate issue. You're right, I'm opening a new issue here[1]. Thanks, Mathieu [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40493 ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-02 10:25 ` Ludovic Courtès 2020-04-02 11:40 ` Mathieu Othacehe @ 2020-04-02 23:27 ` Bengt Richter 2020-04-03 23:17 ` pelzflorian (Florian Pelz) 1 sibling, 1 reply; 40+ messages in thread From: Bengt Richter @ 2020-04-02 23:27 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 Hi all, On +2020-04-02 12:25:37 +0200, Ludovic Courtès wrote: > Hi, > > Mathieu Othacehe <m.othacehe@gmail.com> skribis: > > >> That’s exactly what it does, see (shepherd comm). > >> > >> Perhaps we just need to have the installer service depend on ‘syslogd’, > >> at which point nothing goes to /dev/console? > > > > Heh, I read it too fast, sorry :) The issue was in fact that we are > > calling `start-service' and `stop-service' from `apply-locale' in (gnu > > installer), and printing shepherd messages to shepherd-message-port > > which is stderr by default. > > > > Fixed on wip-installer-help. > > Awesome. > > Do you think that branch is ready for a merge? Or did you want to > further discuss some of the changes? Florian seemed to agree that it’s > a good thing. > I am wondering about hot-plugged keyboards, whether plugged in before power-up or late, after login and GUI terminal activation. I see/imagine several issues. 1) Legacy unices seem just to have accepted any usb device identifying itself as key event generator and merged the events indiscriminately into existing key-event streams, with security issues ignored, and alternate layouts ignored :-/ What I'm writing on now [1] has a US keyboard (which is annoying if I am trying to write swedish, or embarrass myself with my French :), so I am recharging the batteries for an old swedish Logitech kb that has a wireless connection to a USB receiver. (I'll return to report how that worked out -- I think I saw that PureOS was able to handle different-layout keyboards in different concurrent sessions -- different keyboards and displays can be attached to different "seats" -- or something like that, I obviously don't know much yet ;-) Anyway, to the point: even if I'm wrong about PureOS handling concurrent different-layout keyboards, I think that would be a good goal for GuixOS/Hurd/Shepherd to implement. So WDYT about a little kb experimenting to expose potential issues before final decisions? 2) Another issue is that with hot-plugging and booting from external media, keyboard layouts are unknowable ahead of time (except by humans deciding they will only boot from media they know carry KB layout info matching the booting host's KB). So who/what is the first user of keyboard layout info? I think probably the OEM who decided which key should interrupt booting to go into BIOS setup, since the BIOS has to continue with some assumption of keyboard layout. Probably matches the BIOS-developer's kb, hard coded ;-) But consider a "NUC" box, with no predetermined peripherals, just sockets. Plug in the right keyboard or keep rebooting and hitting Esc or Del or F11 and hope you don't trigger anything disastrous. Or get online with another machine and search for how someone succeeded. Filter bad advice. How many times have you gone through that ? ;-) Ok, next user after BIOS, probably some boot loader. Its image can not contain knowledge of what keyboard is the source of key-codes, so it must either receive converted key codes or be able to get the right layout info to do the conversion itself -- or punt, using a US layout for anything and everything. ... Let's see, '-' is '/' and '+' is '-' and ... argh. (recognize install iso experience? setfont sun12x22 helps :) So anyway, eliding, the boot loader gets the root file system loaded and pivots to it and the kernel can figure out keyboards again for itself, maybe. Is this really a good design for gnu guix systems? All that Mach stuff I read April 1st sounded really neat ;-) (I regret having pointed out the date and not letting it run. I apologize for interrupting the fun "joke" ;-/ ) Logitech KB batteries still charging, will have to try that later ... HTH make multiple concurrent different-layout keyboards be part of the future :) > Ludo’. > > > [1] Purism Librem13v4 laptop: an emergency-prompted purchase when my swedish laptop died in US) -- Regards, Bengt Richter ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-02 23:27 ` Bengt Richter @ 2020-04-03 23:17 ` pelzflorian (Florian Pelz) 2020-04-08 7:20 ` Bengt Richter 0 siblings, 1 reply; 40+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-04-03 23:17 UTC (permalink / raw) To: Bengt Richter; +Cc: 40273 On Fri, Apr 03, 2020 at 01:27:43AM +0200, Bengt Richter wrote: > I think I saw that PureOS was able to handle > different-layout keyboards in different concurrent sessions -- different keyboards and displays > can be attached to different "seats" -- or something like that, I obviously don't know much yet ;-) > > Anyway, to the point: even if I'm wrong about PureOS handling concurrent > different-layout keyboards, I think that would be a good goal > for GuixOS/Hurd/Shepherd to implement. From what I understand from <https://github.com/xkbcommon/libxkbcommon/blob/master/doc/quick-guide.md>, there can be per-device keyboard layouts, but they are not handled by XKB options. If a device specifier were added to the keyboard-layout constructor, the device specifier would need to be turned into appropriate xorg.conf MatchUSBID or similar. Regards, Florian ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-03 23:17 ` pelzflorian (Florian Pelz) @ 2020-04-08 7:20 ` Bengt Richter 2020-04-08 9:42 ` Ludovic Courtès 0 siblings, 1 reply; 40+ messages in thread From: Bengt Richter @ 2020-04-08 7:20 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: 40273 Hi Florian, On +2020-04-04 01:17:50 +0200, pelzflorian (Florian Pelz) wrote: > On Fri, Apr 03, 2020 at 01:27:43AM +0200, Bengt Richter wrote: > > I think I saw that PureOS was able to handle > > different-layout keyboards in different concurrent sessions -- different keyboards and displays > > can be attached to different "seats" -- or something like that, I obviously don't know much yet ;-) > > > > Anyway, to the point: even if I'm wrong about PureOS handling concurrent > > different-layout keyboards, I think that would be a good goal > > for GuixOS/Hurd/Shepherd to implement. > > From what I understand from > <https://github.com/xkbcommon/libxkbcommon/blob/master/doc/quick-guide.md>, > there can be per-device keyboard layouts, but they are not handled by > XKB options. If a device specifier were added to the keyboard-layout > constructor, the device specifier would need to be turned into > appropriate xorg.conf MatchUSBID or similar. > > Regards, > Florian Sorry for the delay in replying. Thanks for the informative link! I'm really against pursuing any new design dependencies on X, so even "or similar" sounds iffy to me. Just IMO ;-) I recognize it will be a while before we can ignore X-based apps, but we can stop using it as GUI infrastructure, if Wayland can provide GUI foundation with Xwayland giving X apps a path to the screen via Wayland. Of course Wayland has dependencies on what the kernel can provide, like libdrm stuff. Wayland seems a likely X successor, and represents an opportunity to do GUI without X dependencies, for a cleaner Guix. I can report that tilix as implemented in PureOS on a Librem13v4 provides a workable GUI solution for multiple keyboards, even if it's not what I had in mind ;-) Here is an overview: PureOS is debian-based Purism variant with gnome for desktop etc and I think all composited and displayed by their Wayland, providing xwayland only as a service for apps needing the X interface, but not itself depending on X. tilix is, I think, a pure wayland client implementation, and can provide multiple simultaneous terminal tiles on the screen, overlapping or not. These window tiles are created by typing "tilix" with optional args. Without args it creates a new tile space according to a Default "profile" which you can do a LOT with, but don't need to to demo the keyboard mappings. The first tilix command will normally be typed into a widget that comes up on pressing the super key (some keyboards will have a windows flag on that key :). Subsequent tilix commands can be typed in any tilix terminal, and will produce another terminal tile accordin to parameters in the profile (of which you can create different versions). Choosing a keyboard language (separate dropdown widget at top of screen) in any of these terminal tiles that has focus will set the keyboard mapping for that terminal tile only. Switching focus to another tile will use the the kb mapping chosen for it. Persistence is attached to the terminal tile. So you could have two different language keyboards plugged in and use one to type into one tile terminal and the other for the other. You just have to switch focus to where you want the typing to appear. But this is also a kind of illusion, because both keyboards' untranslated keycodes are apparently merged into the same stream and fed where the focus is. So you can't mix languages on one terminal tile by just typing on the alternate keyboard (as I had wanted)-- you have to go to the language choice widget and temporarily switch there, no matter which keyboard you are typing on. Some keys are obviously the same, so it doesn't matter which keyboard you type those on. It goes to the focused tile and gets translated, but the mapping for those keys is the same. Right now I am in GUI emacs called as editor for mutt, and the language selection has no effect even though when I exit all the way back to the bash where I typed mutt, it will (or should ;). pidparents ? 18587 Ss /usr/bin/bash /home/bokr/bin/pidparents emacs pts/0 18069 Sl+ emacs /home/bokr/.mutt/temp/mutt-LionPure-1000-17715-4020479191039126306 sh pts/0 18068 S+ sh -c emacs '/home/bokr/.mutt/temp/mutt-LionPure-1000-17715-4020479191039126306' mutt pts/0 17715 S+ mutt bash pts/0 13623 Ss /bin/bash tilix ? 13618 Sl /usr/bin/tilix --gapplication-service systemd ? 1644 Ss /lib/systemd/systemd --user systemd ? 1 Ss /sbin/init splash And if I were at the tty initial console, the widget for language change wouldn't be there, since no gnome GUI. I would have to use loadkeys. And back in grub, another world. And back in the BIOS, another. And all considerations repeated for booting from external disks, net, whatever. Phooey ;-) There's gotta be a better way :) That "joke" enthusing about a Mach microkernel sounded good :) -- Regards, Bengt Richter ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-08 7:20 ` Bengt Richter @ 2020-04-08 9:42 ` Ludovic Courtès 2020-04-08 21:11 ` Bengt Richter 0 siblings, 1 reply; 40+ messages in thread From: Ludovic Courtès @ 2020-04-08 9:42 UTC (permalink / raw) To: Bengt Richter; +Cc: 40273 Hi Bengt, Bengt Richter <bokr@bokr.com> skribis: > I'm really against pursuing any new design dependencies on X, > so even "or similar" sounds iffy to me. Just IMO ;-) The XKB database and associated tools is the de facto standard for handling keyboard layouts; it does a great job! It originated in X11 but that’s about the only relation it has with X11. Anyway, please let’s try to keep issues at Debbugs and development discussions focused otherwise it’s easy to all get lost in open-ended discussions while making very little actual progress. :-) Thanks, Ludo’. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts 2020-04-08 9:42 ` Ludovic Courtès @ 2020-04-08 21:11 ` Bengt Richter 0 siblings, 0 replies; 40+ messages in thread From: Bengt Richter @ 2020-04-08 21:11 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 40273 Hi Ludo, On +2020-04-08 11:42:41 +0200, Ludovic Courtès wrote: > Hi Bengt, > > Bengt Richter <bokr@bokr.com> skribis: > > > I'm really against pursuing any new design dependencies on X, > > so even "or similar" sounds iffy to me. Just IMO ;-) > > The XKB database and associated tools is the de facto standard for > handling keyboard layouts; it does a great job! It originated in X11 > but that’s about the only relation it has with X11. > I'm more than ok with declarative data representing a legacy of valuable info. I didn't mean to deprecate that part, sorry. > Anyway, please let’s try to keep issues at Debbugs and development > discussions focused otherwise it’s easy to all get lost in open-ended > discussions while making very little actual progress. :-) > Understood. Sincere apologies for disrupting and/or distracting. I understand the problem. (After all, I'm doing it to myself: It takes me much longer to write than it does to read ;-p ) So, off-topic replies being a problem. naturally I am triggered to think about this problem, and I am tempted to post ideas about automatically diverting off-topic reply posts to guix-offtopic@gnu.org and and automatically only posting references thereto to recipients who would otherwise get the whole thing. But beyond the above, I will restrain myself ;-) Sorry about this off-original-topic post. I guess it is like social distancing to avoid infecting people with distractions ;-/ I will try to practice better hygiene :) -- Regards, Bengt Richter ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2020-04-08 21:12 UTC | newest] Thread overview: 40+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-03-28 13:42 bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts pelzflorian (Florian Pelz) 2020-03-28 19:45 ` Mathieu Othacehe 2020-03-30 10:44 ` pelzflorian (Florian Pelz) 2020-03-30 11:35 ` Mathieu Othacehe 2020-03-30 17:11 ` pelzflorian (Florian Pelz) 2020-03-30 17:31 ` pelzflorian (Florian Pelz) 2020-03-31 15:35 ` Ludovic Courtès 2020-03-31 16:55 ` pelzflorian (Florian Pelz) 2020-04-01 20:33 ` Bengt Richter 2020-04-02 6:24 ` pelzflorian (Florian Pelz) 2020-04-02 9:45 ` Ludovic Courtès 2020-04-03 0:38 ` pelzflorian (Florian Pelz) 2020-04-03 1:11 ` pelzflorian (Florian Pelz) 2020-04-03 13:31 ` pelzflorian (Florian Pelz) 2020-04-03 13:59 ` pelzflorian (Florian Pelz) 2020-04-03 15:20 ` Ludovic Courtès 2020-04-03 15:56 ` pelzflorian (Florian Pelz) 2020-04-05 14:03 ` Ludovic Courtès 2020-04-05 20:02 ` pelzflorian (Florian Pelz) 2020-04-05 21:26 ` Ludovic Courtès 2020-03-29 15:04 ` Ludovic Courtès 2020-03-29 17:16 ` pelzflorian (Florian Pelz) 2020-03-29 17:53 ` Mathieu Othacehe 2020-03-30 10:39 ` Mathieu Othacehe 2020-03-30 12:39 ` pelzflorian (Florian Pelz) 2020-03-31 15:29 ` Ludovic Courtès 2020-04-01 12:49 ` Mathieu Othacehe 2020-03-31 15:28 ` Ludovic Courtès 2020-04-01 12:52 ` Mathieu Othacehe 2020-04-02 10:25 ` Ludovic Courtès 2020-04-02 11:40 ` Mathieu Othacehe 2020-04-06 7:52 ` Ludovic Courtès 2020-04-06 13:14 ` Mathieu Othacehe 2020-04-07 9:49 ` Ludovic Courtès 2020-04-07 17:14 ` Mathieu Othacehe 2020-04-02 23:27 ` Bengt Richter 2020-04-03 23:17 ` pelzflorian (Florian Pelz) 2020-04-08 7:20 ` Bengt Richter 2020-04-08 9:42 ` Ludovic Courtès 2020-04-08 21:11 ` Bengt Richter
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.