When holding a one-shot key and tapping another that would cancel the one-shot
effect, when we release the one-shot key within `hold_time_out`, do not start
the oneshot effect.
This is done by only clearing the `should_cancel_` flag in `loopHook` when
cancellation did happen. If we clear anyway, then the flag set by the
interrupting keypress will be lost by the time we release the one-shot key.
Reported by @ToyKeeper, thanks a lot for the detailed explanation!
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Now that we have key masking functionality provided by KeyboardHardware, use
that instead of going with our own.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When interrupting, we send a report, release all keys, and mask the interrupting
key to avoid issues like sending too many of the interrupting keys. Later on, we
unmask the interrupting key if it has been masked.
This fixes#9, but requires the masking patches to be merged first.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of iterating down from the 32th layer, do so from `max_layers_` instead.
Not only is this more performant, it allows us to have higher layers outside of
Colormap's control.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The goal is to ignore key events from still-held keys in a situation where we
just turned a layer off. Thus, if one holds a momentary layer key, then presses
and holds another key, releases the layer key, we want to ignore the other held
keys until they are released.
This is accomplished by masking all held keys when a momentary layer has been
turned off, and ignoring all masked key events in `handleKeyswitchEvent` until
they are released, when we unmask them.
This should address #150, but requires
keyboardio/Kaleidoscope-Hardware-Model01#9.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
There are situations when one wants to ignore key events for a while, and mask
them out. These newly introduced functions help do that.
They are in the Hardware plugin, because this is where it is most efficient to
implement the masks: the hardware library knows how many bits it needs, and how
best to represent the masks. We use a 32-bit bitmap here, other keyboards may
use a different size, or an entirely different approach too.
This is one part of the fix to address keyboardio/Kaleidoscope#150.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of trying to exclude layer keys, exclude everything with a flag. Thus,
only the basic keys will receive the highlighting treatment, and the rest,
`Prog`, `Any` and the layer keys will not.
Thanks to @chughes87 for the report!
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To avoid issues with static initialization order, move the Mouse & AbsoluteMouse
initialization from the MouseWrapper constructor to MouseWrapper.begin, which
will be called from MouseKeys.begin. Thus, user code does not need to change.
This fixeskeyboardio/Kaleidoscope#140.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
As there are - or at least may be - other keys on the layer, not just NumPad
ones, those should be highlighted too.
Addresses the bulk of keyboardio/Kaleidoscope#149, by comparing the looked up
key with what is directly on the `numPadLayer`: if they are the same, then it is
a key that we assume changed, and do the coloring. If they are different (in
other words, the key on the `numPadLayer` is transparent or off), we skip the
highlight.
The downside is that we highlight layer switching keys too, which we may not
want. That will be addressed separately.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
rather than send key down events for a while before sending a key
release event as we did with the old scheme, this sends the events
paired together as "one shot". This is closer to the spec and what OSX
needs to accept these events
Selene Scriven
Gergely Nagy
Jesse Vincent
Jesse Vincent