Open Roming22 opened 1 year ago
That's because python on an MCU is slow (and KMK isn't super optimized). Can't be easily "fixed" as such. Out of curiosity: what MCU is this on?
A sea-picro, which is an RP2040 based MCU using the pi micro footprint.
I have a suspicion that the slowness can be sidestepped somehow. Likely a tough issue, but keypad library is interrupt driven, so it shouldn't be impossible.
There's already ticks_ms
attached to matrix changes, so if we could say "don't activate chord if matrix changes are this far apart" it would be significantly more precise.
That's not wrong, and in the long run I intended to look into basing timeouts on the KeyEvent
timestamps, rather than now()
. That could result in some funky behaviour though, especially for short timeouts and slow modules.
Another thing I've been looking into is a better data structure for timeouts, like an actual priority queue.
I do not know about the internals of KMK. But if a timer was to be started on the first key press of a potential combo, and was to register an event on timeout, then that could be used to discriminate between a roll and a combo.
Describe the bug I've set my combos to trigger if key presses occur within 45ms. The combo gets triggered on longer delays.
To Reproduce Steps to reproduce the behavior:
Expected behavior The combo should not activate, and individual key presses should be output.
Debug output
Additional context The keys of the combos are MT keys. I would expect the combo and MT delays to be in parallel.
In my example the keys pressed are 't' and 'e', and output
p
instead ofte
. The delay between the key presses is 85ms, almost twice as long as the 45ms timeout configured, and yet the chord gets activated.My layout: xs18.txt