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 <address@hidden> 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