qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.28k stars 39.38k forks source link

NKRO does not work after OS reboot/start on certain setups #2248

Closed rautesamtr closed 2 years ago

rautesamtr commented 6 years ago

Reconnecting the keyboard by plugging it out and back in results in NKRO working as expected. E.g. it honors nkro eeprom setting and reacts correctly by toggling it with MAGIC_TOGGLE_NKRO (keymap_config.nkro).

I was able to observe this behavior both on Windows and Arch Linux on my desktop computer as well as on arch linux on my Macbook Air. It works fine with OSX without reconnecting the board on the same Macbook Air and on Windows on my brothers laptop. Both my Katana60 as well as a Arduino Pro Micro based board I am working on show the same behavior.

Using magic key + s (and magic key + e ) with hid_listen shows that keymap_config.nkro and the eeprom equivalent get set correctly but NKRO just does not work in any tester till the keyboard is restarted in some way e.g. plugging it out and back in or flashing a new firmware.

drashna commented 6 years ago

After updating the repo, does this still happen?

fredizzimo commented 6 years ago

It sounds like the the computer is switching to the boot protocol and remains there for some reason. The setting of the protocol can be found here https://github.com/qmk/qmk_firmware/blob/master/tmk_core/protocol/lufa/lufa.c#L548

You could try to force the normal protocol here https://github.com/qmk/qmk_firmware/blob/master/tmk_core/protocol/lufa/lufa.c#L635, and see if that helps. Or maybe use debug output to print out the values.

This will obviously not fix the root cause, but will at least lead us in the right direction.

rautesamtr commented 6 years ago

Sorry for the delay in response but yes I did some testing with 0.6.1 and the problem still persists.

It looks like that @fredizzimo is right. keyboard_protocol stays 0 on a reboot and only is set to 1 on a replug. Forcing it to 1 like suggested in the following line results in working nkro. https://github.com/qmk/qmk_firmware/blob/1f778684276e90609c183045a72c96c3c12d452c/tmk_core/protocol/lufa/lufa.c#L554

sQVe commented 3 years ago

I'm having this exact issue on my Arch based system and it's frustrating me to bits. I've tried everything I can think of with no success. It seems like the fix ☝🏼 doesn't apply anymore for the later versions of QMK.

I can replicate this issue with 6 different boards, all running QMK, on my system.

Any thoughts @rautesamtr @fredizzimo or anyone else? Would love to get this fixed. 🙏🏼

sQVe commented 3 years ago

💦

So I dove into this tonight and cannot get it to work with bootmagic or in any other "sane" way. I played around with the protocol and the following patch fixes it for me:

--- usb_main.c  2021-08-28 00:25:22.445911030 +0200
+++ usb_main.c.new  2021-08-28 00:25:14.252514288 +0200
@@ -597,7 +597,7 @@

                     case HID_SET_PROTOCOL:
                         if ((usbp->setup[4] == KEYBOARD_INTERFACE) && (usbp->setup[5] == 0)) { /* wIndex */
-                            keyboard_protocol = ((usbp->setup[2]) != 0x00);                    /* LSB(wValue) */
+                            keyboard_protocol = 1;                    /* LSB(wValue) */
 #ifdef NKRO_ENABLE
                             keymap_config.nkro = !!keyboard_protocol;
                             if (!keymap_config.nkro && keyboard_idle) {

I don't know what other implications this might have, so I'd love some insights on that if possible.

dsvensson commented 2 years ago

I have this same issue with my Infinity Ergodox. My motherboard is MSI MAG B550 TOMAHAWK with latest BIOS if that matters. The problem did not happen with my old computer iirc. Tried various USB ports hoping there's some controller variance, but no success. It's not OS related either, happens with both Windows and Linux.

jakemauer commented 2 years ago

So I'm resurrecting this issue as I came here via a Google search. I had this problem with my Massdrop Alt, even with FORCE_NKRO enabled it never worked after boot. I would always have to toggle it on. I tried to make adjustments to the usb C files but the arm files that TMK uses in the Massdrop builds already have keyboard_protocol set to 1.

On a hunch I enabled "Legacy USB support" in my BIOS and it fixed it! NKRO is enabled by default on boot now. For reference I'm on a Gigabyte Aorus Pro Z390 board with an EFI bios.

UNFORTUNATE UPDATE: This didn't seem to fix it. Recent cold boots have resulted in me still having to manually enable NKRO. Dangit.

zvecr commented 2 years ago

This issue has been automatically closed because it has not had any recent activity. If this issue is still valid, re-open the issue and let us know.

IlyasYOY commented 1 year ago

Update: because of this option being on Caps Lock doesn't seem to change input source. Everything works fine if I have NKRO off.

FabienFellay commented 6 months ago

If Google brought you here and the above seems like the issue you have, please, go to issue #23255 where you might find a solution.