From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts Date: Fri, 3 Apr 2020 01:27:43 +0200 Message-ID: <20200402232743.GA2810@LionPure> References: <20200328134202.rgl6usllluoo2b2y@pelzflorian.localdomain> <875zenyzh0.fsf@gnu.org> <20200329171609.puseiw4d4b6cxgd7@pelzflorian.localdomain> <878sjjt5cj.fsf@gmail.com> <87a73wv903.fsf@gnu.org> <87lfnfcqrh.fsf@gmail.com> <87zhbup4ke.fsf@gnu.org> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42349) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK9Gh-0002xn-AY for bug-guix@gnu.org; Thu, 02 Apr 2020 19:29:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jK9Gf-0006aR-W8 for bug-guix@gnu.org; Thu, 02 Apr 2020 19:29:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:57637) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jK9Gf-0006ZL-RN for bug-guix@gnu.org; Thu, 02 Apr 2020 19:29:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jK9Gf-0004ex-Mr for bug-guix@gnu.org; Thu, 02 Apr 2020 19:29:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87zhbup4ke.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 40273@debbugs.gnu.org Hi all, On +2020-04-02 12:25:37 +0200, Ludovic Courtès wrote: > Hi, > > Mathieu Othacehe 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