Hi, I have some dual keys on space and home row. To reduce mistyping, I am trying to add PERMISSIVE_HOLD_PER_KEY on space and IGNORE_MOD_TAP_INTERRUPT_PER_KEY on home row. However, I do not find how to do it in Kaleidoscope firmware. Is their some way of doing it in Kaleidoscope firmware?
1 Like
Kaleidoscope does not use the same system for tap/hold keys as QMK’s Mod-Tap. The plugin that handles them is called Qukeys, and it has a number of configuration parameters that you can adjust in the firmware (you can’t change them from Chrysalis). However, it may be helpful to understand how it differs from the QMK Mod-Tap system first.
The primary determining factor for the output of a qukey is the order in which the two keys are released. If you press a “dual key”, press another key, the release the two keys, you’ll get the “mod” value if you release the other key first, and the “tap” value if you release the qukey first.
If you want more information, the documentation is available on ReadTheDocs, and if you are getting unintended output, I would be happy to recommend settings to address the specific problems that you see, depending on the types of errors. Unfortunately, I’m not really familiar with QMK, so I’m not sure how to translate the PERMISSIVE_HOLD_PER_KEY & IGNORE_MOD_TAP_INTERRUPT_PER_KEY values to concepts in Kaleidoscope, but I’m sure I can help direct you to configuration options that will help reduce errors that you’re seeing.
Thank you. I did not see that there is an option for setMinimumHoldTime and setMinimumPriorInterval. I think that two shall solve the problem.
BTW, is it possible to set setMinimumHoldTime per key? I would like the two values bigger for home rows and smaller for bottom rows.
No, I haven’t implemented any per-key timing settings, because of the relatively large amount of memory required. I’m also inclined to believe that the benefits would be negligible compared to the added complexity.
Likely due to the differences from QMK, there have frequently been misconceptions about how Qukeys works, so I want to emphasize that it is designed primarily to work by means of key release order, and that the various timeout settings only exist to help limit unintended output in cases where the user’s input has been imprecise. If you want to use Qukeys without a reliable keyswitch release order, you’re likely to see unintended output no matter what you do—it can’t read your mind.
Out of curiosity, what type of errors were you seeing? Unintended modifiers, unintended non-modifiers, or both?
Both. I have both modifier on home row and on the bottom. On the modifiers of the home row, I have unintended modifers. On the shift modifiers on the bottom where on thumb places, I have unintended non-modifiers.
I just increased change the minimimHoldTime and move the bottom shift modifiers onto the home row. The problem is resoleved.
1 Like
One thing you can do with a generic Qukey object is to make the modifier (or layer shift) the primary value (in the keymap), and set the alternate value (defined in the Qukey) to the printable symbol. This will cause Qukeys to output the modifier in all rollover cases, behaving more like the SpaceCadet plugin (or, for the QMK analogy, if this cheatsheet is correct, HOLD_ON_OTHER_KEYPRESS). This lets you have keys with different characteristics, some of which will err on the side of “tap” and others towards “hold” behaviour, without introducing the complexity of per-key settings.
1 Like