[Bug] Key behave as if it was stuck and repeats the last typed letter

[jakubgros]

Describe the Bug

When typing, the keyboard sometimes behaves as if a key was pressed and held. It sends a signal to the PC until I click any key or disconnect a receiver. I think it's not a hardware problem because I've tried turning off the keyboard once the bug appeared and it was still sending the signal to PC until I disconnected a receiver.

The bug is hard to reproduce and I'm not sure what causes it. I think that it might be related to pressing multiple keys at the same time. What's interesting, is that my keyboard sometimes works perfectly and then it gets into a state where it's more likely to enter the bug. Restarting the keyboard/receiver doesn't help to get out of the "increased likelihood of bug state". After some time it gets fixed by itself.

Right before the bug is triggered, when I'm typing, it hangs for ~1s(nothing is typed into PC even though I'm pressing keys) and it starts repeating the last pressed key. It looks similar to the behaviour on the video attached to the #18805 issue, but the difference in my case is that I can see constantly the typed characters until the freeze, after which the last key starts to repeat.

I'm not sure whether it's a problem with qmk_firmware of any of qmk tooling or with my setup. I'm not sure how to debug it. Any advice?

Keyboard Used

redox_w

Link to product page (if applicable)

redox wireless

Operating System

Edition Windows 10 Enterprise
Version 21H2
Installed on ‎3/‎10/‎2022
OS build 19044.2251
Experience Windows Feature Experience Pack 120.2212.4180.0

qmk doctor Output

❯ qmk doctor
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.0
Ψ QMK home: /home/sg315781/qmk_firmware
Ψ Detected Linux (WSL).
Ψ Git branch: master
Ψ Repo version: 0.19.2
⚠ Git has unstashed/uncommitted changes.
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 9.2.1
Ψ Found avr-gcc version 5.4.0
Ψ Found avrdude version 6.3-20171130
Ψ Found dfu-util version 0.9
Ψ Found dfu-programmer version 0.6.1
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2022-09-18 10:01:17 +0000 --  (0e9d558b5)
Ψ - lib/chibios-contrib: 2022-10-03 18:09:41 +0200 --  (bb8356fb)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/pico-sdk: 2022-09-19 18:02:44 +0200 --  (8d56ea3)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ QMK is ready to go, but minor problems were found 

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

None

Additional Context

qmk --version = 1.1.0
qmk_firmware: commit 2709b6e

My keyboard config: https://github.com/jakubgros/redox_wireless

I'm putting a symbolic link into the qmk_firmware/keyboards/redox_w directory, build it using compile.sh script from the repository and flash the keyboard using the qmk_toolbox.exe.

[getreuer]

Right before the bug is triggered, when I'm typing, it hangs for ~1s(nothing is typed into PC even though I'm pressing keys) and it starts repeating the last pressed key.

Just to clarify, the keyboard is connected to the computer wirelessly over Bluetooth, is that right? I wonder if the stuck keys are the result of Bluetooth communication occasionally getting interrupted, just after a key press event and the computer missing the corresponding key release event.

[jakubgros]

Yes, it's connected wirelessly to the computer. This is the module I have that is used as a receiver. Based on what I found on the internet it's a Bluetooth module. Though, I'm not 100% sure how it works, because I'm not that much into hardware and I'm confused why an additional Bluetooth module had to be added, instead of using the one from laptop.

The connection scheme looks as follows:

-- = cable
.... = wireless connection
PC ------receiver . . . . . . . . . . . . . . . . . . . . . .  \/ . . . . . . . . . . \/    
                                                           left keyboard      right keyboard

[fauxpark]

This board does not use Bluetooth, all three modules communicate over the Gazell protocol, and the receiver module transmits the key state to the actual MCU via UART.

https://github.com/mattdibi/redox-w-firmware
https://github.com/qmk/qmk_firmware/blob/master/keyboards/redox_w/matrix.c

[jakubgros]

I managed to gather a bit more useful information about the problem. When my keyboard got into "increased likelihood of bug state", I tried to restart the keyboard but it didn't help. Then I plugged it into another computer and it worked there without any problem. I could still observe the problematic behaviour when I plugged it back into the initial PC. Based on that, I assume that the problem might be on the PC side of communication.

[korompaiistvan]

I also ran into this issue on a kbd67rev2 board but could not figure out what was causing it. the frequency of this bug seemed to correlate with my machine's CPU load

[sneakret]

I am seeing the exact same symptoms (keyboard events lost when CPU load is high -- input pausing, then acting like a key is being held down, then dropping a couple keystrokes, then resuming normal function). Like @jakubgros I can't reproduce it on my other computer. I have ruled out QMK as the cause in my environment, because I connected a non-QMK keyboard and the problem persisted.

[mrschyte]

I'm having a similar issue when my keyboard is connected through a KVM switch. I have set TAP_CODE_DELAY to 10ms which greatly reduced the frequency of this happening. I wonder if the same workaround would apply here as well.

[mrschyte]

I'm having a similar issue when my keyboard is connected through a KVM switch. I have set TAP_CODE_DELAY to 10ms which greatly reduced the frequency of this happening. I wonder if the same workaround would apply here as well.

I was able to completely resolve my issue by setting a higher USB_POLLING_INTERVAL_MS. My KVM seems to support only a 125Hz polling rate (8ms). The default 1000Hz polling rate results in dropped packets and if the dropped packet corresponds to a key-up event, it acts as if the key was stuck.

[fauxpark]

That didn't do anything. Due to how USB works fundamentally, the value of USB_POLLING_INTERVAL_MS is more of a suggestion to the host; the keyboard does not actually send data faster or slower unless the host requests it more or less frequently.

[mrschyte]

It did work in my case. I guess the KVM allows a higher polling interval to be negotiated than it can support.

[niscient-green]

Had the same issue. SplitKB Kyria rev3 on QMK attached to KVM. Putting the line below in config.h worked.
#define USB_POLLING_INTERVAL_MS 10

[Adrian-Grimm]

Same bug here with a KBD fans KBD8X MKII behind a KVM with VIA Firmware - I upgraded from an old version from 2021 and now I have this bug. Same with most recent QMK.

[MrWolf-K9]

I thought I had the same issue but I simply forgot to call unregister_code() after register_code() in my custom macro.