When Qukeys stops event processing from its `onKeyswitchEvent()` handler, it's
because the event should be treated as non-existent (in most cases, it's merely
delayed). This keeps the keyboard state array from getting updated, as well as
completely stopping event processing.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This replaces the `Layer.live_composite_keymap_[]` cache with a representation
of the keyboard's current state as an array of `Key` objects, one per key on the
keyboard. In this new array, an idle key will have the value `Key_Transparent`,
and a pressed key will have the value of whatever key it's currently mapped to
in the keymap (or whatever value the active set of plugins has assigned to
it). A value of `Key_NoKey` will mask that key until it is released.
If a plugin returns `ABORT` from its `onKeyswitchEvent()` handler, that means
that the keymap cache should not be updated. It's especially important to have
this occur after plugins like OneShot and Qukeys, where the key can stay
active (or become active) after the physical keyswitch has been released.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This will allow plugin handlers to send one of three different signals to the
calling hook functions, with three different interpretations:
`OK`: Continue calling the next handler.
`EVENT_CONSUMED`: Don't proceed to the next handler, but signal to the hook
function's caller that an event was handled successfully.
`ABORT`: Stop processing, and signal to the hook function's caller that the
event should be ignored.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Instead of only aborting hook functions if a handler returns `EVENT_CONSUMED`,
only continue abortable hooks if a handler returns `OK`. For existing core
plugins, this shouldn't make any difference because none of them use the `ERROR`
return value.
Also rename `shouldAbortOnConsumedEvent` to better match the new conditional.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This testcase checks to make sure that the keyboard state array gets cleared by
`handleKeyswitchEvent()` when a plugin returns `EVENT_CONSUMED`.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This adds a testcase for rollover from a TapDance key to the key that interrupts
the sequence, and a testcase for a TapDance key that times out while held.
I also adjusted the timing of the existing testcases to match the new version of
TapDance.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This testcase checks for any changes to existing values in Kaleidoscope-Ranges,
with the goal of preventing backwards-incompatible changes that will affect
existing EEPROM keymaps configured via Chrysalis.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This makes it possible for a testcase to include source files from plugin
directories. When the plugins got pulled out of the main Kaleidoscope source
dir, plugin header files became unavailable to testcases, but these files are
useful in some instances.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This replaces the magic number `24576` with the old definition of the start of
the Macros plugin's `Key` range, to make it clear that it will match bitwise
tests for "not a plugin key" (the two high bits are both zeros) and the
`SYNTHETIC` flags bit.
I also elaborated on the reasons for keeping the existing `Key` values stable
and added a comment addressing the more likely case where new values are being
added, rather than fighting the last war and focusing only on the one legacy
plugin range that exists outside the canonical plugin range, whose values have
already been incorporated here.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Some headers in the file Model01Side.h were included inside the namespace
`kaleidoscope::driver::keyboardio` instead of being left in the global
namespace, where they should have been.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This implements a new `FocusSerial` command: `plugins`. The `plugins` command
will reply back with a list of plugins enabled in the firmware. The list is not
exhaustive, only plugins that opt-in to this mechanism will be listed. It is
opt-in, because for a lot of plugins, having them listed isn't useful in a
practical sense.
The goal with this feature is to allow Chrysalis to detect plugins that would
affect what keys it offers, or which additional settings it displays, and do so
in a consistent way. This is why IdleLEDs has an `onNameQuery` handler too, even
though it can be detected otherwise: for consistency.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The option `--build-properties` was deprecated in v0.14.0 of arduino-cli. This
change uses the new option `--build-property` instead if the version of
arduino-cli being called is newer than that, thus avoiding deprecation warning
messages and innoculating the build system against the removal of the deprecated
version of the option.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Instead of safeguarding against an unrecoverable blank layer state by
guaranteeing that layer 0 is always active (and therefore always at the bottom
of the layer stack), we safeguard by a move to layer 0 if the only active layer
is deactivated.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Macro keycodes pre-date the Ranges plugin, so they previously had a keycode that
sorted before ranges::FIRST. For the sake of backwards compatibility, we want to
keep using the same keycodes.
Fixes#1010.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The `INSTANTIATE_WEAK_HOOK_FUNCTION` claimed that it's there for v1 API
compatibility alone - it is not. It allows us to have sketches that use no
plugins too, without them having to use `KALEIDOSCOPE_INIT_PLUGINS()` with a
dummy plugin.
We'd need a dummy plugin because `KALEIDOSCOPE_INIT_PLUGINS()` does not support
being invoked with an empty plugin list, due to technical reasons. From an
end-user point of view, not using the macro is much preferable to using it with
a dummy plugin. We can't automatically inject a dummy plugin either, again, due
to technical reasons.
Fixes#1005.
Signed-off-by: Jesse Vincent <jesse@keyboard.io>
Michael Richters
Jesse Vincent
Gergely Nagy
Gergely Nagy