Just a few quick notes: - I have just retried to integrate my 'setkey' and 'setnumpad' commands into my input terminal module, and it works. I have no idea what I did wrong when I tried it earlier on, but it obviously must have been something silly. - The INT16H/10H extended keyboard input call, used by my input terminal module, is not powerful enough to fully support a keymap. For instance, the Belgian keyboard layout uses quite a few <AltGr> (or <RightAlt>) key combinations for various characters, and the call doesn't distinguish between <LeftAlt> and <RightAlt>. Furthermore, not all keys report their <Alt> combination. As a result, under the Belgian keyboard layout, there would be no way to input, for example, a backslash character. Of course, my 'setkey' command runs into similar problems, so that is not a perfect solution either. - Since it's a bit silly to replace one not entirely satisfying solution with another, I will not further pursue a solution that is based upon my input terminal modules; that really seems somewhat like a waste of time. Instead, I'll try and find out what is going wrong with 'at_keyboard', and see if I can fix it. - In any case, I can continue to use my input terminal for now, until I can work out a better option.
2015-07-12 14:25 GMT+02:00 Luc Van Rompaey <luc.vanromp...@gmail.com>: > > 2015-07-12 12:03 GMT+02:00 Andrei Borzenkov <arvidj...@gmail.com>: > >> В Sat, 11 Jul 2015 20:28:20 +0200 >> Luc Van Rompaey <luc.vanromp...@gmail.com> пишет: >> >> > 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 >> > >> >> >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
