Ok, that's interesting then. So I guess maybe what's happened is:
The Bluetooth HID packet gets sent
Espruino sees this, and calls the callback thinking it has actually got sent
The original HID packet wasn't received so a resend is attempted
The hidkbd code tries to send a second HID packet, but it fails because the original was still being sent
Does the 'key stuck on' problem happen more often than just the missed key?
If it is the problem above then I might be able to do something about sendHIDReport such that it didn't report the key as sent until it had actually 'gone', but I'm not sure I could do much about the missing initial keypress, as that might just be due to a particularly bad connection and the send just timing out.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Ok, that's interesting then. So I guess maybe what's happened is:
Does the 'key stuck on' problem happen more often than just the missed key?
If it is the problem above then I might be able to do something about
sendHIDReport
such that it didn't report the key as sent until it had actually 'gone', but I'm not sure I could do much about the missing initial keypress, as that might just be due to a particularly bad connection and the send just timing out.