keyboard_protocol stuck at 0 after OS reboot/start on certain setups about qmk_firmware

[danei]

@FabienFellay For grub, it sometimes requires toggling legacy USB support in BIOS/UEFI.
Grub itself checks boot class and protocol from descriptor when initializing usb keyboard, and aborts when mismatch:

if (usbdev->descdev.class != 0 
      || usbdev->descdev.subclass != 0 || usbdev->descdev.protocol != 0)
    return 0;

  if (usbdev->config[configno].interf[interfno].descif->subclass
      != USB_HID_BOOT_SUBCLASS
      || usbdev->config[configno].interf[interfno].descif->protocol
      != USB_HID_KBD_PROTOCOL)
    return 0;

The logic very likely differs from BIOS/UEFI. If grub hands over as is to OS, it's possible OS won't re-initialize usb keyboard again as grub has initialized it.
[edit]
Can you try OS detection & reset feature as described here? OS_DETECTION_ENABLE = yes and #define OS_DETECTION_KEYBOARD_RESET

[FabienFellay]

I have now more hints about how to reproduce the issue.

I have 2 identical machines: one with Windows 10 only and one with a dual boot Windows 10 / Ubuntu. The above-described bug only affects the machine that has the dual boot. I don't know what causes the issue in the first place, but the dual boot machine may shortly pass through a transient (not really visible) bios-like menu that somehow makes the keyboard being stuck with keyboard_protocol to 0.

Can a QMK collaborator reproduce the issue based on those new elements (machines with dual-boot) ?

[FabienFellay]

@danei Thank you very much! OS detection + reset feature helped: adding OS_DETECTION_ENABLE = yes in rules.mk and #define OS_DETECTION_KEYBOARD_RESET in my config.h just solved this issue.

Indeed, all my dual-boot machines that were impacted by this issue are now showing a keyboard_protocol to 1 right after the OS boots and NKRO is finally working directly without an additional manual reset.

I let a link to this issue in the issue #2248 (this might help some people).

Thank you! 👍