I guess QEMU/KVM does some translation itself, explaining it works.

In Grub2 code, there is a hardcoded keymap for layout_us:

./grub-core/commands/keylayouts.c:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
static struct grub_keyboard_layout layout_us = { 
  .keyboard_map = { 
    /* Keyboard errors. Handled by driver.  */
    /* 0x00 */   0,   0,   0,   0,  

    /* 0x04 */ 'a',  'b',  'c',  'd', 
    /* 0x08 */ 'e',  'f',  'g',  'h',  'i', 'j', 'k', 'l',
    /* 0x10 */ 'm',  'n',  'o',  'p',  'q', 'r', 's', 't',
    /* 0x18 */ 'u',  'v',  'w',  'x',  'y', 'z', '1', '2',
    /* 0x20 */ '3',  '4',  '5',  '6',  '7', '8', '9', '0',
    /* 0x28 */ '\n', '\e', '\b', '\t', ' ', '-', '=', '[',
    /* According to usage table 0x31 should be mapped to '/'
       but testing with real keyboard shows that 0x32 is remapped to '/'.
       Map 0x31 to 0. 
    */
    /* 0x30 */ ']',   0,   '\\', ';', '\'', '`', ',', '.',
[...]
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


I think this explains what the customer sees:
Lenovo P71:
- pressing 'a' shows keycode 0x1c which translates into 0x79 ('y' ascii code)
- pressing 'e' shows keycode 0x0d which translates into 0x6a ('j' ascii code)

keycode 0x1c (pressing 'a') maps to "y" indeed from above
keycode 0x0d (pressing 'e') maps to "j" indeed from above

Today I enabled "atkeyb" debugging and added some more traces.
I also hacked the #if condition on line 357 below:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
345 static void
346 set_scancodes (void)
347 {
 :
357 #if 0 && !USE_SCANCODE_SET
358   current_set = 1;
359   return;
360 #else
361 
362   grub_keyboard_controller_write (grub_keyboard_controller_orig
363                                   & ~KEYBOARD_AT_TRANSLATE);
364 
365   write_mode (2);
366   current_set = query_mode ();
367   grub_dprintf ("atkeyb", "returned set %d\n", current_set);
368   if (current_set == 2)
369     return;
370 
371   write_mode (1);
372   current_set = query_mode ();
373   grub_dprintf ("atkeyb", "returned set %d\n", current_set);
374   if (current_set == 1)
375     return;
376   grub_printf ("No supported scancode set found\n");
377 #endif
378 }
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This has the effect to force entering the #else clause which enables to detect the current_set.
With this current_set was set to "2" and keyboard was working fine after applying the FR keymap.

It's unclear to me how all this works, but for sure with current code (#if !USE_SCANCODE_SET clause on line 357), current_set is hardcoded to 1 which makes the keyboard return invalid keycodes.

I could verify that Upstream Grub2 has the exact same issue.

I've submitted a PR and requested phcoder to have a look and explain the current code.

https://github.com/rhboot/grub2/pull/74

So I spent almost all my day working on this.

First the patch proposed upstream doesn't work:

- it makes my T460s handle the french keyboard
- but it breaks on my Asus N53SN

For some reason, on my Asus N53SN query_mode() returns "set2" but in fact "set1" is active internally.

Additionally, if I enable "at_keyboard" in UEFI Grub, my QEMU/KVM is UEFI also breaks with the patch.


The good news is executing set_scancode() all the time (so hacking the "#if !USE_SCANCODE" to disable the block) appears to work on all the systems I have:

- my T460s
- my Asus N53SN
- a QEMU/KVM in UEFI

I'm pretty convinced this is the solution to adopt here.

The patch proposed upstream doesn't work - see Comment 11. Moving this bug back to assigned.

Based on comment 28 and sanity testing switching to verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (grub2 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:0852