I’m using home row mods on a colemak/miryoku inspired layout configured through Chrysalis. Ended up swapping out my switch on the S key to a click bar that provides very clear audible feedback when a key is pressed. Wasn’t sure if I just wasn’t sufficiently pressing the key to hit actuation, but it’s very obvious with the click.
Rapid repeated presses of the S key will often produce no output. Problem goes away when removing the secondary action feature.
For the moment, avoiding the issue by trying bottom row mods instead, as they’re keys that will seldom need to be repeated.
I want to suggest turning off the tap-repeat feature that’s designed to let you produce a “hold” with the primary value of the key. This would require compiling your own firmware, however, and since you’re using Chrysalis, this might not be worth the trouble.
I’ve compiled plenty in the past. Would be amazing if this keyboard was supported by QMK.
I think I’m going to move away from mod keys on this keyboard though, because they often get stuck, too. I may recompile in kaleidoscope just to get autoshift.
Reading the definition of Qukeys.setMaxIntervalForTapRepeat(ms), it doesn’t sound like the behavior I’m experiencing is intended. It’s not defined in the default sketch. I’m guessing I should set it to zero?
I’m guessing my keymap is broken due to eeprom issues? I can’t find documentation on how to reset it.
There was a recently fixed bug in Qukeys that might produce these symptoms for some people. It’s unknown why some Qukeys users have a lot of trouble with this bug, and some have no trouble with it. I think the fix hasn’t yet made its way into a release, though.
unfortunatelly it did not fix the issue. when i have a secondary function (alt) on my “s” key it still often misses the key… like “assert”–>“asert” or “issue”–>“isue”
really frustrating…