From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZEGKW-0001aL-Ug for mharc-grub-devel@gnu.org; Sun, 12 Jul 2015 08:26:00 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEGKT-0001Zz-Gm for grub-devel@gnu.org; Sun, 12 Jul 2015 08:25:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZEGKR-0006Fu-Nk for grub-devel@gnu.org; Sun, 12 Jul 2015 08:25:57 -0400 Received: from mail-lb0-x22d.google.com ([2a00:1450:4010:c04::22d]:33847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEGKR-0006FT-98 for grub-devel@gnu.org; Sun, 12 Jul 2015 08:25:55 -0400 Received: by lbnk3 with SMTP id k3so111757373lbn.1 for ; Sun, 12 Jul 2015 05:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=brvHoFj3OHNAnbP4W/KzadvnITitDa+PhrXV1t5ePKE=; b=0rQfSE5qcgDfd4kQiZmFnjf9IepyKaXwvmqrke2bDP9TkmR0MGV/4wqtIbnyPWZLRy fZ2Q2OMjsYAnYuvHgvybICTg9f9Uh/K/gQRYKwB+f0LtPBKsyGysUmwC3W0YIDhlYuc5 Cl+m2sMBtIcBLyDWZDmfoawop9LnVQvKgLKINIW403JRln5JPcKHJWvGUqv3yg5tt/6M M4jBHcN2ks9rxAyyyHj+ol33zszB/dPDTNbC8A+DwuMnU8N9Qk0UgFUyVmsseAwrDoWT giQeKRjgo++C6Mi5r73DY5Ur66KKoEsicUU+nfE5N3rwhg61v2CxJSjb3wUVHJPLqv70 35jQ== MIME-Version: 1.0 X-Received: by 10.112.55.70 with SMTP id q6mr24651724lbp.99.1436703954501; Sun, 12 Jul 2015 05:25:54 -0700 (PDT) Received: by 10.114.93.39 with HTTP; Sun, 12 Jul 2015 05:25:54 -0700 (PDT) In-Reply-To: <20150712130330.0ba74e02@opensuse.site> References: <1436639304-5365-1-git-send-email-luc.vanrompaey@gmail.com> <20150712130330.0ba74e02@opensuse.site> Date: Sun, 12 Jul 2015 14:25:54 +0200 Message-ID: Subject: Re: [PATCH 0/4] Implement the 'setkey' command to allow changing the keyboard map From: Luc Van Rompaey To: Andrei Borzenkov Content-Type: multipart/alternative; boundary=001a1133d13cdb081f051aacb425 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22d Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 12:25:59 -0000 --001a1133d13cdb081f051aacb425 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-07-12 12:03 GMT+02:00 Andrei Borzenkov : > =D0=92 Sat, 11 Jul 2015 20:28:20 +0200 > Luc Van Rompaey =D0=BF=D0=B8=D1=88=D0=B5=D1=82= : > > > Legacy GRUB had a 'setkey' command to remap the keyboard keys. > > GRUB2 no longer has this command. Instead, it provides an 'at_keyboard= ' > > input terminal module, which can load a GRUB keymap. > > Unfortunately, at least on the i386-pc platform, 'at_keyboard' is > problematic, > > in that it easily causes hangups. > > > > Do you have some more data? Fixing it would be preferable. > > For starters, the first keystroke after I activate 'at_keyboard', will no= t get processed, even though the countdown until automatic boot will get stopped. Further keystrokes are something of a hit-and-miss, until the system no longer responds to keyboard input. At that point, either some kind of crash will happen, after which the computer reboots, or I need to perform a hard reset (power cycle). If I do get to the point where I can chainload another GRUB copy (with a default config as automatically generated under, e.g., Debian or Ubuntu), then apparently, the keystrokes that didn't get processed earlier on, suddenly seem to be run, ... after which the system locks up, and a hard reset is, again, required. I would love to fix the 'at_keyboard' issue, and I will if I can. I cannot at this point promise anything, though. Plus, something less convoluted is a great exercise to get a feel for the GRUB code. > For now, I'm unsure what needs to be done to fix 'at_keyboard', which is > why > > I decided to look for a different solution. Whether I can fix the > 'at_keyboard' > > input terminal, and in what time frame, remains to be seen. > > > > This patch set reintroduces a 'setkey' command, to support changing the > keyboard > > map, similarly to what was possible under Legacy GRUB. > > > > GRUB2 already has framework for custom keyboard layouts. Why not reuse > grub_term_map_key() from keylayouts same as at_keyboard and > usb_keyboard do? Map scan code to GRUB_KEYBOARD_* and let > grub_term_map_key() to care about keyboard mapping. This has additional > advantage of supporting localized keyboard tables (your approach does > not, it only changes ASCII layouts). Hmm... good idea. I'll look into this. Thanks for the pointer. > > The first patch just makes a simple edit to a comment line in the > 'memory.h' > > header file. It updates the URL for the 'bios_data_area.html' web page= , > which > > contains helpful information about BIOS, and specifically, the keyboard > > interface. > > > > You already sent this one, it hardly belongs to this patch series. > Sorry about that. > > > The second patch implements the 'nusetkey' module, which provides the > 'setkey' > > command. In addition, it provides a 'setnumpad' command, to change the > > behavior of the numeric keypad. > > > > Why NumLock is not sufficient? > NumLock is 'sufficient' in that it works. I implemented the 'always output numeric character' feature because I find it annoying that the numeric keypad doesn't produce numeric characters by default. The BIOS of my laptop doesn't offer me the option of automatically turning NumLock on, which is an added annoyance. And, last but not least, my laptop doesn't have a NumLock LED, so I cannot even visually verify if NumLock is on or off. I use the numeric keypad only ever to get numeric characters anyway (which is what it should be there for in the first place, in my not so humble opinion), and since the feature was pretty easy to implement, I decided to go for it. > > > The third patch implements the 'nuconsole' input terminal, which works = in > > conjunction with the 'nusetkey' module to support keyboard map changes. > > > > Making them two different modules in your case is pointless; nuconsole > cannot work without nusetkey and nusetkey is used only by nuconsole. > I won't disagree that it seems pointless. In fact, I initially wanted to integrate all of my code in one module, but that didn't work. I got some kind of error about some out-of-memory or table-full condition, or some such (don't remember exactly; failed to take notes). It seemed to me that terminal input and/or output modules couldn't provide their own commands. I may be wrong, though, in which case I must have done something awfully stupid. > Also, something like ext_keyboard would probably be more appropriate. > Agreed.. will go for the 'ext_keyboard' name. > > > Finally, the fourth patch provides updates to the GRUB manual. > > It documents the 'keymap' command (which loads a keyboard map for use b= y > > the 'at_keyboard' or 'usb_keyboard' input terminals), plus the 'setkey' > and > > 'setnumpad' commands implemented by the 'nusetkey' module. > > > > Luc Van Rompaey (4): > > update URL to bios_data_area.html on comment line > > implement the nusetkey module > > implement the nuconsole input terminal > > add documentation for keymap, setkey, and setnumpad commands > > > > docs/grub.texi | 150 +++++++++ > > grub-core/Makefile.core.def | 12 + > > grub-core/commands/i386/pc/nusetkey.c | 583 > ++++++++++++++++++++++++++++++++++ > > grub-core/term/i386/pc/nuconsole.c | 111 +++++++ > > include/grub/i386/pc/memory.h | 2 +- > > include/grub/i386/pc/nusetkey.h | 25 ++ > > 6 files changed, 882 insertions(+), 1 deletion(-) > > create mode 100644 grub-core/commands/i386/pc/nusetkey.c > > create mode 100644 grub-core/term/i386/pc/nuconsole.c > > create mode 100644 include/grub/i386/pc/nusetkey.h > > > > --001a1133d13cdb081f051aacb425 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2015-07-12 12:03 GMT+02:00 Andrei Borzenkov <arvidjaar@gmail.com&g= t;:
=D0=92 Sat,= 11 Jul 2015 20:28:20 +0200
Luc Van Rompaey <luc.vanromp= aey@gmail.com> =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

> Legacy GRUB had a 'setkey' command to remap the keyboard keys.=
> GRUB2 no longer has this command.=C2=A0 Instead, it provides an 'a= t_keyboard'
> input terminal module, which can load a GRUB keymap.
> Unfortunately, at least on the i386-pc platform, 'at_keyboard'= is problematic,
> in that it easily causes hangups.
>

Do you have some more data? Fixing it would be preferable.

For starters, the first keyst= roke after I activate 'at_keyboard', will not get processed, even t= hough the countdown until automatic boot will get stopped.
Fu= rther keystrokes are something of a hit-and-miss, until the system no longe= r responds to keyboard input.
At that point, either some kind= of crash will happen, after which the computer reboots, or I need to perfo= rm a hard reset (power cycle).

If I do get to the point w= here I can chainload another GRUB copy (with a default config as automatica= lly generated under, e.g., Debian or Ubuntu), then apparently, the keystrok= es that didn't get processed earlier on, suddenly seem to be run, ... a= fter which the system locks up, and a hard reset is, again, required.
I would love to fix the 'at_keyboard' issue, and I wil= l if I can. I cannot at this point promise anything, though. Plus, somethin= g less convoluted is a great exercise to get a feel for the GRUB code.
<= /div>

> For now, I'm unsure what needs to be done to fix 'at_keyboard&= #39;, which is why
> I decided to look for a different solution.=C2=A0 Whether I can fix th= e 'at_keyboard'
> input terminal, and in what time frame, remains to be seen.
>
> This patch set reintroduces a 'setkey' command, to support cha= nging the keyboard
> map, similarly to what was possible under Legacy GRUB.
>

GRUB2 already has framework for custom keyboard layouts. Why not reu= se
grub_term_map_key() from keylayouts same as at_keyboard and
usb_keyboard do? Map scan code to GRUB_KEYBOARD_* and let
grub_term_map_key() to care about keyboard mapping. This has additional
advantage of supporting localized keyboard tables (your approach does
not, it only changes ASCII layouts).=C2=A0

Hmm... good= idea. I'll look into this. Thanks for the pointer.
=C2=A0
=
> The first patch just makes a simple edit to a comment line in the '= ;memory.h'
> header file.=C2=A0 It updates the URL for the 'bios_data_area.html= ' web page, which
> contains helpful information about BIOS, and specifically, the keyboar= d
> interface.
>

You already sent this one, it hardly belongs to this patch series.

Sorry about that.

> The second patch implements the 'nusetkey' module, which provi= des the 'setkey'
> command. In addition, it provides a 'setnumpad' command, to ch= ange the
> behavior of the numeric keypad.
>

Why NumLock is not sufficient?

N= umLock is 'sufficient' in that it works.
I implemente= d the 'always output numeric character' feature because I find it a= nnoying that the numeric keypad doesn't produce numeric characters by d= efault.
The BIOS of my laptop doesn't offer me the option= of automatically turning NumLock on, which is an added annoyance.
And, last but not least, my laptop doesn't have a NumLock LED, so= I cannot even visually verify if NumLock is on or off.

I= use the numeric keypad only ever to get numeric characters anyway (which i= s what it should be there for in the first place, in my not so humble opini= on), and since the feature was pretty easy to implement, I decided to go fo= r it.

> The third patch implements the 'nuconsole' input terminal, whi= ch works in
> conjunction with the 'nusetkey' module to support keyboard map= changes.
>

Making them two different modules in your case is pointless; nuconso= le
cannot work without nusetkey and nusetkey is used only by nuconsole.

I won't disagree that it seems po= intless.
In fact, I initially wanted to integrate all of my c= ode in one module, but that didn't work.
I got some kind of error about some out-of-memory or table-full=20 condition, or some such (don't remember exactly; failed to take notes).=
It seemed to me that terminal input and/or output modules co= uldn't provide their own commands.
I may be wrong, though= , in which case I must have done something awfully stupid.
=C2=A0<= /div>
Also, something like= ext_keyboard would probably be more appropriate.

Agree= d.. will go for the 'ext_keyboard' name.

> Finally, the fourth patch provides updates to the GRUB manual.
> It documents the 'keymap' command (which loads a keyboard map = for use by
> the 'at_keyboard' or 'usb_keyboard' input terminals), = plus the 'setkey' and
> 'setnumpad' commands implemented by the 'nusetkey' mod= ule.
>
> Luc Van Rompaey (4):
>=C2=A0 =C2=A0update URL to bios_data_area.html on comment line
>=C2=A0 =C2=A0implement the nusetkey module
>=C2=A0 =C2=A0implement the nuconsole input terminal
>=C2=A0 =C2=A0add documentation for keymap, setkey, and setnumpad comman= ds
>
>=C2=A0 docs/grub.texi=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 150 +++++++++
>=C2=A0 grub-core/Makefile.core.def=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 12 +
>=C2=A0 grub-core/commands/i386/pc/nusetkey.c | 583 ++++++++++++++++++++= ++++++++++++++
>=C2=A0 grub-core/term/i386/pc/nuconsole.c=C2=A0 =C2=A0 | 111 +++++++ >=C2=A0 include/grub/i386/pc/memory.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A02 +-
>=C2=A0 include/grub/i386/pc/nusetkey.h=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 25 ++
>=C2=A0 6 files changed, 882 insertions(+), 1 deletion(-)
>=C2=A0 create mode 100644 grub-core/commands/i386/pc/nusetkey.c
>=C2=A0 create mode 100644 grub-core/term/i386/pc/nuconsole.c
>=C2=A0 create mode 100644 include/grub/i386/pc/nusetkey.h
>


--001a1133d13cdb081f051aacb425--