bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Mathieu Othacehe]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Mathieu Othacehe]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Mathieu Othacehe]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Mathieu Othacehe]

> 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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

[-- 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)

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Mathieu Othacehe]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Mathieu Othacehe]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Bengt Richter]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

[-- 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))

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Mathieu Othacehe]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Bengt Richter]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[pelzflorian (Florian Pelz)]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Mathieu Othacehe]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Mathieu Othacehe]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Bengt Richter]

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

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Ludovic Courtès]

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’.

bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts

[Bengt Richter]

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