Hi there,

A french Red Hat customer reported that in Legacy mode (the code isn't used with UEFI), immediately after switching |terminal_input| to |at_keyboard|, the keyboard was just not usable due to invalid key mappings. This happens on various laptop models from various manufacturers with French keyboards, but should also happen with any keyboard layout.

I could reproduce this as well on my Lenovo T460 which has a French keyboard, but not on a QEMU/KVM.

After adding debugging, I could find out that the value |ps2_state.current_set| is hardcoded to *1* due to having the following piece of code with |USE_SCANCODE_SET| set to 0:

|#if !USE_SCANCODE_SET grub_dprintf ("atkeyb", "set_scancodes: forcing current_set = 1\n"); ps2_state.current_set = 1; return; #else |

The |USE_SCANCODE_SET| is set to 0 due to this:


#if defined (GRUB_MACHINE_MIPS_LOONGSON) || defined (GRUB_MACHINE_QEMU) || defined (GRUB_MACHINE_COREBOOT) || defined (GRUB_MACHINE_MIPS_QEMU_MIPS)
#define USE_SCANCODE_SET 1
#else
#define USE_SCANCODE_SET 0
#endif


If I make sure USE_SCANCODE_SET is always defined to 1, causing the rest of the set_scancodes() function to execute, which I understand is some kind of "auto-detection" of the set to use, I can see that on my laptop the |current_set| should be set to *2*, and this effectively fixes the issue: Keys pressed map to expected keys (e.g. without loading a FR keymap, |a| maps to |q|, |z| to |w|, |e| is kept as is, etc.).

After loading the FR keymap, a maps to a, etc., as expected.

Could someone explain why this |USE_SCANCODE_SET| is set to 0, hence current_set hardcoded for real x86_64 hardware?

See also https://github.com/rhboot/grub2/pull/74 implementing the debugging and hack to force detecting the current set in set_scancodes().

Best regards,

Renaud METRICH

Attachment: OpenPGP_0x5D129094FB6E4326.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to