-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NKRO breaks layer-tap with "extended" keycodes #2253
Comments
The only difference with |
Thanks for your help! The thing is, from what I can see this behavior is happening on both Windows and Ubuntu, and doesn't happen for the < 12 function keys e.g. with |
Yes, after setting up wireshark for USB capture I can confirm that a single tap of my So there is definitely a bug in ZMK over USB + Extended Report NKRO. I'm not familiar with the codebase so it's going to take a while for me to set up a development environment and insert print statements everywhere for me to understand. Complicating the issue is the fact that I can get the If anyone more knowledgeable can infer what is going wrong from this information please feel free to point me in the right direction! |
Another thing is that, even more rarely, once I get the "right combination" of spammy presses to get the |
OK, I believe this is a bug in upstream Zephyr. By inserting print statements I see ZMK making a call to Weird. I've been testing this on an Adv360. |
Okay, found the problem. There is a data race in I conclude that copying the buffer is not part of the Zephyr function's contract (the docs are ambiguous, and on first glance would cause me to guess Pull request incoming. |
The fix is in #2257. Tested working on a real Adv360. |
In my experience , |
@jhorology Unfortunately the bug isn't not having enough bytes sent to the USB endpoint, but rather a race condition caused by an ambiguous API in upstream Zephyr (which they acknowledge, but can't change---the relevant conversation is zephyrproject-rtos/zephyr#71306). So ZMK is going to have to work around this (at least until apparently a new USB subsystem for Zephyr which will be available at some point in the future). |
The binding
< my_layer F24
doesn't work properly with NKRO on, even with extended reporting enabled. I observe that: withCONFIG_ZMK_HID_KEYBOARD_NKRO_EXTENDED_REPORT=n
I never see anF24
at all when tapping (as expected), but withCONFIG_ZMK_HID_KEYBOARD_NKRO_EXTENDED_REPORT=y
I only infrequently get aF24
keycode after spamming, alternating between the layer-tap key and another ordinary e.g.&kp A
key. Tapping the layer-tap key by itself, I never see anyF24
s at all. Replacing the original layer-tap binding with< my_layer A
works fine in any case.However, by disabling NKRO altogether with
CONFIG_ZMK_HID_REPORT_TYPE_NKRO=n
the problem completely goes away. I am connected over USB. Does anyone know what the cause of this could be?The text was updated successfully, but these errors were encountered: