grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/4] Implement the 'setkey' command to allow changing the key


From: Luc Van Rompaey
Subject: Re: [PATCH 0/4] Implement the 'setkey' command to allow changing the keyboard map
Date: Tue, 14 Jul 2015 19:25:02 +0200

Just a few quick notes:

2015-07-12 14:25 GMT+02:00 Luc Van Rompaey <address@hidden>:

2015-07-12 12:03 GMT+02:00 Andrei Borzenkov <address@hidden>:
В Sat, 11 Jul 2015 20:28:20 +0200
Luc Van Rompaey <address@hidden> пишет:

> 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 not 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 by
> 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
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]