• @Sebastian: I also agree on the lost "release" packet theory: a repeated keystroke can almost always stopped pressing the corresponding button again.
    Regarding the operating distance, I generally use HID and experience this issue when I am at least 2 m from my PC. Only when I stay at a "safe" distance (< 0.5 m) during the whole duration of hidkbd app operation the issue seems not to be happening.
    As already mentioned in my first post, I am pretty sure that the problem lies in the Bluetooth reconnection procedure. If I force a disconnection and wait for reconnection, I can reproduce the bug even at a safe distance. Probably the increase in keystroke misses and repeats rate that you experience during long range operation is the consequence of a reconnection triggered after a momentary lost signal disconnection.

    @Gordon: in my use case (media playback control) the 'key stuck on' problem is much more harmful than the missed key. So yes, I would be very grateful even only for a fix for the repeated keystrokes problem!
    So, if I got this right from your post, in the BLE HID protocol a sort of ACK is expected after each keystroke. If this is true, maybe even the missing initial keypress could wait until a timeout and report a failure as an exception of kb.tap() call. This exception could be caught from user code such as hidkbd and possibly trigger another kb.tap() call or print an error message on screen. This, combined with my reconnection routine described in post #9, should do the trick!
    What do you think? Can this be feasible?

About

Avatar for Franzo @Franzo started