# Qukeys rewrite (may fix rollover issues)

**URL:** <https://community.keyboard.io/t/qukeys-rewrite-may-fix-rollover-issues/2835>\
**Category:** Plugins\
**Created:** [May 3, 2019, 7:00pm UTC](https://community.keyboard.io/t/qukeys-rewrite-may-fix-rollover-issues/2835 "2019-05-03T19:00:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)\
**Post date:** [May 3, 2019, 7:00pm UTC](https://community.keyboard.io/t/qukeys-rewrite-may-fix-rollover-issues/2835/1 "2019-05-03T19:00:07Z")

</div>

For people who are still having difficulty using Qukeys to add modifiers to home row keys (or other keys that are primarily used for printable characters), I have rewritten Qukeys completely, with a new rollover grace period algorithm. Right now, it can be found as a draft pull request against Kaleidoscope ([#640](https://github.com/keyboardio/Kaleidoscope/pull/640)).

In order to use it, you may want to make two changes to your sketch. First, if you define any `Qukey` objects (rather than just using the DualUse-style definitions in the keymap), you may want to change the constructor from this one:

```auto
Qukey(layer, row, col, alternate_key);

```

…to this new one:

```auto
Qukey(layer, KeyAddr(row, col), alternate_key);

```

…in order to suppress some deprecation warnings.

In addition, the `setTimeout()` function has also been deprecated, in favor of `setHoldTimeout()`, which is functionally equivalent.

Most important is that the rollover grace period works in a completely new way, and has a different method of controlling its settings. The old way was to set a fixed amount of time in milliseconds as a “release delay”. After a qukey was released, if there was a subsequent key press, Qukeys would wait that period of time for the subsequent key to be released before determining the state that the qukey would end up in. So you could do the following:

1. Press qukey Q (`a` / `shift`) – _(@ time = t1 )_
2. Press X – _(@ time = t2 )_
3. Release Q – _(@ time = t3 )_
4. Release X – _(@ time = t4 )_

If the release delay was set to 20ms (`Qukeys.setReleaseDelay(20)`), and less than 20ms elapsed between events #3 and #4 ( _t4 - t3 \> 20ms_ ), the qukey would become `shift` instead of `a`. This helped, but was clearly not good enough.

The new system records both the press and release times of the keys, and uses a percentage as a threshold, by calling `Qukeys.setOverlapThreshold(pct)`, where `pct` is a number between `1` (1%) and `100` (100%). Using the above example, it compares the duration of the subsequent key’s press ( _Tx = t4 - t2_ ) to the duration of the overlap ( _Tr = t4 - t3_ ). Suppose we set the threshold to 80%. If _Tr_ is more than 80% of _Tx_ (because X was released soon after Q), the qukey will become `a`. If _Tr_ is less than 80% of _Tx_ (because X was held longer), the qukey will become `shift`.

This new algorithm automatically adjusts to different typing speeds, so it should do much better than the old one. When testing it out, I was surprised at how low I could set the percentage and still reliably get the output I intended without triggering unwanted modifiers. Whereas I used to caution against setting the old release delay too high (above ~20ms), the new overlap threshold parameter might work well at values as low as 50%.

---

<div class="post-metadata">

**Author:** ![nickzylstra](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/nickzylstra/32/2868_2.png) [@nickzylstra](https://community.keyboard.io/u/nickzylstra)\
**Post date:** [September 17, 2019, 1:17am UTC](https://community.keyboard.io/t/qukeys-rewrite-may-fix-rollover-issues/2835/2 "2019-09-17T01:17:41Z")

</div>

thanks for the update! reporting on use in case it helps -

for my typing style i found the default settings not much different than the previous version - which for me meant accidental opt+i and cmd+h on occasion among others. Changing the setOverlapThreshold to 95% seems to make a big difference though.

layout for reference:  
[http://www.keyboard-layout-editor.com/#/gists/533277b2845dbbf0e685ad14a6455f91](http://www.keyboard-layout-editor.com/#/gists/533277b2845dbbf0e685ad14a6455f91)

> <https://github.com/nickzylstra/keyboardio/blob/master/Model01-Firmware.ino>