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

  • Done
  • quality assurance status badge
Details
4 participants
  • Bengt Richter
  • Ludovic Courtès
  • Mathieu Othacehe
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
pelzflorian (Florian Pelz)
Severity
important
P
P
pelzflorian (Florian Pelz) wrote on 28 Mar 2020 14:42
(address . bug-guix@gnu.org)
20200328134202.rgl6usllluoo2b2y@pelzflorian.localdomain
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
P
P
pelzflorian (Florian Pelz) wrote on 29 Mar 2020 19:16
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40273@debbugs.gnu.org)
20200329171609.puseiw4d4b6cxgd7@pelzflorian.localdomain
On Sun, Mar 29, 2020 at 05:04:11PM +0200, Ludovic Court�s wrote:
Toggle quote (3 lines)
> 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


Regards,
Florian
M
M
Mathieu Othacehe wrote on 29 Mar 2020 19:53
(address . bug-guix@gnu.org)
878sjjt5cj.fsf@gmail.com
Hey,

Toggle quote (5 lines)
> 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
M
M
Mathieu Othacehe wrote on 28 Mar 2020 20:45
(address . bug-guix@gnu.org)(address . 40273@debbugs.gnu.org)
87a740nu0u.fsf@gmail.com
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
L
L
Ludovic Courtès wrote on 29 Mar 2020 17:04
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 40273@debbugs.gnu.org)
875zenyzh0.fsf@gnu.org
Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (15 lines)
> 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’.
M
M
Mathieu Othacehe wrote on 30 Mar 2020 12:39
(address . bug-guix@gnu.org)(address . 40273@debbugs.gnu.org)
877dz2p1mx.fsf@gmail.com
Hey,

Toggle quote (4 lines)
> * 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
P
P
pelzflorian (Florian Pelz) wrote on 30 Mar 2020 12:44
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 40273@debbugs.gnu.org)
20200330104449.ahyivwdn62g6jluw@pelzflorian.localdomain
On Sat, Mar 28, 2020 at 08:45:05PM +0100, Mathieu Othacehe wrote:
Toggle quote (5 lines)
> 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
M
M
Mathieu Othacehe wrote on 30 Mar 2020 13:35
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 40273@debbugs.gnu.org)
875zemoz26.fsf@gmail.com
Toggle quote (5 lines)
> 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.

Toggle quote (17 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 30 Mar 2020 14:39
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 40273@debbugs.gnu.org)
20200330123916.qwpfyrt6vzluxrna@pelzflorian.localdomain
On Mon, Mar 30, 2020 at 12:39:50PM +0200, Mathieu Othacehe wrote:
Toggle quote (6 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 30 Mar 2020 19:11
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 40273@debbugs.gnu.org)
20200330171113.njx7wstlmace45xk@pelzflorian.localdomain
On Mon, Mar 30, 2020 at 01:35:29PM +0200, Mathieu Othacehe wrote:
Toggle quote (10 lines)
> 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
Toggle diff (46 lines)
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)
P
P
pelzflorian (Florian Pelz) wrote on 30 Mar 2020 19:31
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 40273@debbugs.gnu.org)
20200330173112.u242ipx36fbmeuzk@pelzflorian.localdomain
On Mon, Mar 30, 2020 at 07:11:13PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (4 lines)
> 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.
L
L
Ludovic Courtès wrote on 31 Mar 2020 17:28
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
87a73wv903.fsf@gnu.org
Hi!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

Toggle quote (7 lines)
> * 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’.
L
L
Ludovic Courtès wrote on 31 Mar 2020 17:29
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 40273@debbugs.gnu.org)
875zekv8yo.fsf@gnu.org
Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

Toggle quote (7 lines)
>> * 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?

Toggle quote (4 lines)
> 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’.
L
L
Ludovic Courtès wrote on 31 Mar 2020 17:35
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
871rp8v8oi.fsf@gnu.org
Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (15 lines)
> 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?

Toggle quote (4 lines)
> ++ 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.

Toggle quote (2 lines)
> ++ 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’.
P
P
pelzflorian (Florian Pelz) wrote on 31 Mar 2020 18:55
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200331165559.6yfowbvtuoth6vdw@pelzflorian.localdomain
On Tue, Mar 31, 2020 at 05:35:41PM +0200, Ludovic Courtès wrote:
Toggle quote (3 lines)
> I think we can have both Alt-Shift and what Mathieu implemented, no?
>

Yes, both would be best, what Mathieu implemented is more
discoverable.

Toggle quote (3 lines)
> 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.

Toggle quote (4 lines)
> 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.

Toggle quote (6 lines)
> 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
M
M
Mathieu Othacehe wrote on 1 Apr 2020 14:49
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40273@debbugs.gnu.org)
87mu7vcqww.fsf@gmail.com
Hello Ludo,

Toggle quote (2 lines)
> 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.

Toggle quote (7 lines)
>
>> 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
M
M
Mathieu Othacehe wrote on 1 Apr 2020 14:52
(name . Ludovic Courtès)(address . ludo@gnu.org)
87lfnfcqrh.fsf@gmail.com
Hey,

Toggle quote (5 lines)
> 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
B
B
Bengt Richter wrote on 1 Apr 2020 22:33
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
20200401203318.GA6142@LionPure
Hi Florian,

On +2020-03-31 18:55:59 +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (44 lines)
> 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

Could this be helpful?

Also this has more extensive info on creating/modifying keymaps and
getting systemd to get them going:

I don't know if this is useful, but seems like you can affect things
early in the boot sequence (from the man page):
Toggle snippet (6 lines)
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.

Toggle quote (5 lines)
> 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 :)

Toggle quote (7 lines)
>
> Thank you.
>
> Regards,
> Florian
>

--
Regards,
Bengt Richter
P
P
pelzflorian (Florian Pelz) wrote on 2 Apr 2020 08:24
(name . Bengt Richter)(address . bokr@bokr.com)
20200402062408.zrapcqfguenlcu5b@pelzflorian.localdomain
On Wed, Apr 01, 2020 at 10:33:18PM +0200, Bengt Richter wrote:
Toggle quote (9 lines)
> 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:



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.


Toggle quote (4 lines)
> > 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
L
L
Ludovic Courtès wrote on 2 Apr 2020 11:45
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87k12yql0i.fsf@gnu.org
Hello Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (8 lines)
> 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’.
Toggle diff (38 lines)
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))
L
L
Ludovic Courtès wrote on 2 Apr 2020 12:25
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
87zhbup4ke.fsf@gnu.org
Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

Toggle quote (12 lines)
>> 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’.
M
M
Mathieu Othacehe wrote on 2 Apr 2020 13:40
(name . Ludovic Courtès)(address . ludo@gnu.org)
874ku2cdyw.fsf@gmail.com
Hello,

Toggle quote (4 lines)
> 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

B
B
Bengt Richter wrote on 3 Apr 2020 01:27
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200402232743.GA2810@LionPure
Hi all,

On +2020-04-02 12:25:37 +0200, Ludovic Courtès wrote:
Toggle quote (23 lines)
> 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 :)

Toggle quote (5 lines)
> Ludo’.
>
>
>

[1] Purism Librem13v4 laptop: an emergency-prompted purchase when my swedish laptop died in US)
--
Regards,
Bengt Richter
P
P
pelzflorian (Florian Pelz) wrote on 3 Apr 2020 02:38
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200403003816.oywdf75mj7yjzygj@pelzflorian.localdomain
On Thu, Apr 02, 2020 at 11:45:01AM +0200, Ludovic Courtès wrote:
Toggle quote (3 lines)
> 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.

Toggle quote (3 lines)
> (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/.*”.



Toggle quote (7 lines)
> 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.


Toggle quote (5 lines)
>
> 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

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
but no bug at Savannah. I will not open a bug I suppose, also the
GRUB manual says many keymaps don’t work well.


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
P
P
pelzflorian (Florian Pelz) wrote on 3 Apr 2020 03:11
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40273@debbugs.gnu.org)
20200403011146.umme6xgat3hnabpv@pelzflorian.localdomain
On Fri, Apr 03, 2020 at 02:38:16AM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (2 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 3 Apr 2020 15:31
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40273@debbugs.gnu.org)
20200403133152.mz6tr6cftb3gkrdb@pelzflorian.localdomain
On Fri, Apr 03, 2020 at 02:38:16AM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (3 lines)
> 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.
P
P
pelzflorian (Florian Pelz) wrote on 3 Apr 2020 15:59
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40273@debbugs.gnu.org)
20200403135917.t4jxlgpt7yjmk467@pelzflorian.localdomain
On Fri, Apr 03, 2020 at 02:38:16AM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (3 lines)
> 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
L
L
Ludovic Courtès wrote on 3 Apr 2020 17:20
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87o8s8k348.fsf@gnu.org
Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (7 lines)
> 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.

Toggle quote (5 lines)
>> (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).

Toggle quote (9 lines)
>> 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.

Toggle quote (10 lines)
>> 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?

Toggle quote (4 lines)
> 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

Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 3 Apr 2020 17:56
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200403155630.k5pfssn3brdbfxbp@pelzflorian.localdomain
On Fri, Apr 03, 2020 at 05:20:23PM +0200, Ludovic Courtès wrote:
Toggle quote (8 lines)
> > 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.



Toggle quote (6 lines)
> 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!!



Toggle quote (13 lines)
>
> >> 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
P
P
pelzflorian (Florian Pelz) wrote on 4 Apr 2020 01:17
(name . Bengt Richter)(address . bokr@bokr.com)
20200403231750.ddmqx6ekr35eye2u@pelzflorian.localdomain
On Fri, Apr 03, 2020 at 01:27:43AM +0200, Bengt Richter wrote:
Toggle quote (8 lines)
> 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
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
L
L
Ludovic Courtès wrote on 5 Apr 2020 16:03
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87mu7qhvw5.fsf@gnu.org
Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (13 lines)
> 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’.
P
P
pelzflorian (Florian Pelz) wrote on 5 Apr 2020 22:02
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200405200212.4thmiaookkfwguh6@pelzflorian.localdomain
On Sun, Apr 05, 2020 at 04:03:54PM +0200, Ludovic Courtès wrote:
Toggle quote (2 lines)
> 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:

Toggle diff (34 lines)
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
L
L
Ludovic Courtès wrote on 5 Apr 2020 23:26
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87mu7phbew.fsf@gnu.org
Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (6 lines)
> 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:


:-/

Toggle quote (8 lines)
> 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’.
L
L
Ludovic Courtès wrote on 6 Apr 2020 09:52
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
87o8s5f3uy.fsf@gnu.org
Hi Mathieu,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

Toggle quote (7 lines)
>> 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.)

Toggle quote (10 lines)
> 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’.
M
M
Mathieu Othacehe wrote on 6 Apr 2020 15:14
(name . Ludovic Courtès)(address . ludo@gnu.org)
87r1x07o4h.fsf@gmail.com
Hey,

Toggle quote (3 lines)
> 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:

Toggle snippet (3 lines)
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.

Toggle quote (3 lines)
> 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
L
L
Ludovic Courtès wrote on 7 Apr 2020 11:49
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
878sj7bp7u.fsf@gnu.org
Hi!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

Toggle quote (13 lines)
>> 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!

Toggle quote (7 lines)
>> 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’.
M
M
Mathieu Othacehe wrote on 7 Apr 2020 19:14
(name . Ludovic Courtès)(address . ludo@gnu.org)
871rozmd4l.fsf@gmail.com
Hey,

Toggle quote (10 lines)
> 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

B
B
Bengt Richter wrote on 8 Apr 2020 09:20
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
20200408072018.GA17715@LionPure
Hi Florian,

On +2020-04-04 01:17:50 +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (19 lines)
> 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
L
L
Ludovic Courtès wrote on 8 Apr 2020 11:42
(name . Bengt Richter)(address . bokr@bokr.com)
878sj671pq.fsf@gnu.org
Hi Bengt,

Bengt Richter <bokr@bokr.com> skribis:

Toggle quote (3 lines)
> 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’.
B
B
Bengt Richter wrote on 8 Apr 2020 23:11
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200408211104.GA2529@LionPure
Hi Ludo,

On +2020-04-08 11:42:41 +0200, Ludovic Courtès wrote:
Toggle quote (11 lines)
> 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.

Toggle quote (4 lines)
> 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
L
L
Ludovic Courtès wrote on 9 Apr 2020 14:37
control message for bug #40273
(address . control@debbugs.gnu.org)
874kts4yxt.fsf@gnu.org
severity 40273 important
quit
?
Your comment

This issue is archived.

To comment on this conversation send an email to 40273@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 40273
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch