Le 14 juil. 2015 19:25, "Luc Van Rompaey" <luc.vanromp...@gmail.com> a écrit : > > 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. Yep. I've run into the same problem when I was investigating possibility of keymap with BIOS. Only few keyboards end up functional under those restrictions. You might have better luck of you read some of this data from BDA directly. I have few others comments as to code style but I skip them as I'm not even sure it's a viable solution at all. > 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.
Most likely you just need to add code to disable keyboard inferior INT1 AFAIR > 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 >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
