When releasing a qukey, allow a short timeout in case a subsequent key was released
effectively simultaneously, treating that near-simultaneous release as intended to use the
alternate (i.e. modifier) keycode.
Any keyswitch events without real physical addresses were injected by other plugins and
should not be processed by Qukeys. There was an interaction with OneShot that prevented
the two plugins from working together because OneShot sends events with a (row, col)
address of `UNKNOWN_KEYSWITCH_LOCATION` (i.e. 255, 255). This meant that if a OneShot
modifier was on when a Qukey was pressed, it would fill up the queue with bogus-address
versions of the Qukey, which would then get flushed in the primary state, cancelling the
OneShot and producing an un-modified, repeating primary keycode, causing both plugins to
fail.
With this change, Qukeys reads DualUse key defs from the keymap, and treats them as
Qukeys, within the limitations of normal DualUse keys. Primary keycodes can only be
unmodified, basic keys, and alternate keycodes can only be modifiers or layer-switch
keys.
Layer changes didn't take effect immediately, and a ShiftToLayer(n) alternate keycode was
never released properly, so it was effectively a LockLayer(n) key. This patch fixes both
problems.
Fixes#28
When the value returned by `millis()` overflows (after ~two months of runtime), a straight
comparison to the end time would fail. This wasn't a really big deal, but it is possible
to do it correctly, and in the process, reduce the size of the time values stored from 32
bits to 16 bits (~one minute), since the largest conceivable useful timeout is measured in
seconds (at most).
We need to prevent infinite loops, and also stop handling keyswitch events when flushing
the queue, but if we do this by setting the `INJECTED` bit in `keyswitch_state` when
calling `handleKeyswitchEvent()`, then other plugins will ignore those events, which is
not what we want; we need them to process those events as if they were real
keypresses. The solution is to use a static boolean to let us know if the queue is being
flushed.
After restoring the current report, if we don't add the keycode for the current key back
in (by calling `handleKeyswitchEvent()` with the "held" state flags if the flushed key is
still held), we'll accidentally leave that keycode out of the next report.
fixes#13
KeyboardioHID isn't going to get a function to copy the previous
report to the current one, but it is now making the current and
previous HID reports public. This is a much better solution all
around, as it allows us to save and restore the current report in the
midst of a scan, while still sending a modified version of the old
report.
Michael Richters
Harry Mills