aboutsummaryrefslogtreecommitdiffstats
path: root/src/hci/keymap/keymap_al.c
Commit message (Collapse)AuthorAgeFilesLines
* [console] Include mappings for AltGr-Shift-<key>Michael Brown2022-02-161-0/+1
| | | | | | | | | | | | | | | | | | | The BIOS console's interpretation of LShift+RShift as equivalent to AltGr requires the shifted ASCII characters to be present in the AltGr mapping table, to allow AltGr-Shift-<key> to be interpreted in the same way as AltGr-<key>. For keyboard layouts that have different ASCII characters for AltGr-<key> and AltGr-Shift-<key>, this will potentially leave the character for AltGr-<key> inaccessible via the BIOS console if the BIOS requires the use of the LShift+RShift workaround. This theoretically affects the numeric keys in the Lithuanian ("lt") keyboard layout (where the numerals are accessed via AltGr-<key> and punctuation characters via AltGr-Shift-<key>), but the simple workaround for that keyboard layout is to avoid using AltGr and Shift entirely since the unmodified numeric keys are not remapped anyway. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Fix definition of unreachability for remapped keysMichael Brown2022-02-151-0/+5
| | | | | | | | | | | | | | The AltGr remapping table is constructed to include only keys that are not reachable after applying the basic remapping table. The logic currently fails to include keys that are omitted entirely from the basic remapping table since they would map to a non-ASCII character. Fix this logic by allowing the remapping tables to include null mappings, which are then elided only at the point of constructing the C code fragment. Reported-by: Christian Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Treat dead keys as producing their ASCII equivalentsMichael Brown2022-02-151-0/+2
| | | | | | | | Treat dead keys in target keymaps as producing the closest equivalent ASCII character, since many of these characters are otherwise unrepresented on the keyboard. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Support AltGr to access ASCII characters via remappingMichael Brown2022-02-151-0/+8
| | | | | | | | | | | | | Several keyboard layouts define ASCII characters as accessible only via the AltGr modifier. Add support for this modifier to ensure that all ASCII characters are accessible. Experiments suggest that the BIOS console is likely to fail to generate ASCII characters when the AltGr key is pressed. Work around this limitation by accepting LShift+RShift (which will definitely produce an ASCII character) as a synonym for AltGr. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Allow for named keyboard mappingsMichael Brown2022-02-151-2/+9
| | | | | | | | Separate the concept of a keyboard mapping from a list of remapped keys, to allow for the possibility of supporting multiple keyboard mappings at runtime. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Handle remapping of scancode 86Michael Brown2022-02-101-0/+2
| | | | | | | | | | | | | | | | | The key with scancode 86 appears in the position between left shift and Z on a US keyboard, where it typically fails to exist entirely. Most US keyboard maps define this nonexistent key as generating "\|", with the notable exception of "loadkeys" which instead reports it as generating "<>". Both of these mapping choices duplicate keys that exist elsewhere in the map, which causes problems for our ASCII-based remapping mechanism. Work around these quirks by treating the key as generating "\|" with the high bit set, and making it subject to remapping. Where the BIOS generates "\|" as expected, this allows us to remap to the correct ASCII value. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Update genkeymap to work with current databasesMichael Brown2022-02-101-0/+1
| | | | | | | | Rewrite genkeymap.pl in Python with added sanity checks, and update the list of keyboard mappings to remove those no longer supported by the underlying "loadkeys" tool. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Try to avoid problems caused by keycode 86Michael Brown2011-03-161-0/+1
| | | | | | | | | | | | | | | | | The "us" keyboard layout contains a mapping for keycode 86 (which seems not to correspond to any physical key on many US keyboards) to the ASCII character '<'. This mapping causes conflicts with the mapping for keycode 51, which also maps (with shift) to '<'. Change the keyboard mapping generator to choose the lowest keycode for each ASCII character as indicating the relevant mapping to use, on the basis that a lower keycode roughly indicates a "more normal" key. On a German keyboard, which has keys for both keycode 51 and keycode 86 present, this causes '<' to be remapped to ';', which is a closer match to typical user expectations. Reported-by: Sven Dreyer <sven@dreyer-net.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Add keymap generatorMichael Brown2011-03-161-0/+31
Inspired by LILO's keytab-lilo.pl, genkeymap.pl uses "loadkeys -b" to obtain a Linux keyboard map, and generates a file keymap_xx.c in hci/keymap. Signed-off-by: Michael Brown <mcb30@ipxe.org>