This allows plugins to override the current LED mode just before the LED sync is
done (i.e. after the mode sets the LED colors, but before those changes are
pushed to the hardware.)
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This class should help plugins that implement `onKeyswitchEvent()` to ensure
that they won't process the same event more than once.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
There's no need to trigger a keyboard HID report after processing a layer
change, so stop processing before calling `prepareKeyboardReport()` if
`event.key` is a layer change `Key`.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The new version of the layer change `Key` handler is more consistent with the
other `KeyEvent` handling functions, and properly checks for a second layer
shift key being held when releasing the first one.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This defines four new event handlers for plugins to use with the forthcoming
redesigned main event loop:
- `onKeyEvent(KeyEvent &event)`
- `onPhysicalKeyEvent(KeyEvent &event)`
- `beforeReportingState(const KeyEvent &event)`
- `onAddToReport(Key key)`
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This allows it to return correct `KeyEvent` values when used by plugins that
need to track that information for delaying events.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The `KeyEvent` type will encapsulate all of the data that will be passed to the
new generation of event handler functions.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
With a non-zero default for tap-repeat, the timing of events changed, causing
this testcase to fail.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This is not complete, but it does test the two basic cases of a double-tap and a
tap-then-hold (to produce a single primary key value hold in output) on all
three types of qukeys (Generic, DualUse, SpaceCadet).
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This change gives Qukeys the ability to repeat a primary keycode by
tapping the key, then immediately pressing and holding it. While doing
this, the extra release and press of the key are suppressed, so it
looks to the host just like a simple press-and-hold event, which is
particularly nice for users of macOS apps that use Cocoa, where
holding letter keys is the "standard" way of accessing accented
characters.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The new items have been added to the end of the list (before `SAFE_START`),
where they belong.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
It was failing to exclude `MoveToLayer()` keys, so it would return `true`
incorrectly for them.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This key makes any held key (or otherwise active key, most likely OneShot keys)
sticky when it toggles on.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This is a special OneShot key that makes any subsequently-pressed key sticky,
regardless of its value.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This adds a new feature to OneShot: it can now (optionally) treat
modifiers and layer-shift keys as automatic OneShot keys, with
functions to enable and disable this feature for modifiers and
layer-shifts independently.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Deprecates OneShot direct-access configuration variables, and replaces them with
setter functions:
- `time_out` => `setTimeout()`
- `hold_time_out` => `setHoldTimeout()`
- `double_tap_time_out` => `setDoubleTapTimeout()`
Deprecating public member variables is tricky, but possible. I've created new,
private member variables, and added code to keep them in sync with the
deprecated public ones for now.
Also of note: The old `OneShot.inject()` function should now be unnecessary for
most purposes. It still works, but has a potential undesirable side effect. It
now needs to pick a physical keyswitch address to use for the injected OneShot
key, and that key will not be usable for its normal value until that OneShot key
is deactivated. Because of this, use of `inject()` is not strongly discouraged.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This is a complete rewrite of OneShot, based on the keymap cache
redesign. This allows OneShot to abort the release of a key, causing
its cache entry to stay valid if it's in an active state after the key
is released, allowing us to fix#896 (double-tapping a layer shift key
doesn't make it sticky).
Instead of tracking `Key` values, OneShot now uses two bitfields of
the keyboard in order to track the OneShot state of every valid
`KeyAddr` independently. This could enable the creation of a OneShot
"meta" key, which could be used as a way to make any key on the
keyboard exhibit OneShot behaviour.
The new OneShot plugin immediately replaces the OneShot `Key` value
with its corresponding "normal" key, and activates its OneShot status
by setting one bit in one of the bitfields.
Also included:
* A rewrite of LED-ActiveModColor that makes it compatible
with the new OneShot, and add support for Qukeys
* Updates to Escape-OneShot for compatibility and efficiency
* Minor updates to Qukeys
* The new KeyAddrBitfield class
KeyAddrBitfield:
This class can be used to represent a binary state of the physical key
addresses on the keyboard. For example, ActiveModColor can use to to
mark all the keys which should be highlighted at any given time. It
includes a very efficient iterator, which returns only `KeyAddr`
values corresponding to bits that are set in the bitfield. It checks a
whole byte at a time before examining individual bits, so if most bits
are unset most of the time, it's very fast, and suitable for use in
hooks that get called every cycle.
ActiveModColor:
This makes LED-ActiveModColor compatible with Qukeys, and removes its
16-modifier limit, while simultaneously reducing it's footprint in RAM
and eliminating a potential buffer overrun bug where it could have
written past the end of its state array.
Fixes#882Fixes#894Fixes#896
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
It's now being used by more than one plugin, and is likely to get used by at
least a third, if not more.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Because the active key for redial was getting cached as the key being pressed,
Redial would only ever see a key toggled on event for `Key_Redial`. It would
then set `redial_held_` to `true`, but it would never get set to `false` on the
key's release.
This change both fixes it and simplifies the plugin as it is adapted to the
keyboard state array by doing away with unnecessary state variables, including
`redial_held_`.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This is an extensive rewrite, but I think it simplifies the logic and makes the
plugin's code easier to follow.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This is a major rewrite of TapDance, taking advantage of the keyboard state
array and the `KeyAddrEventQueue` class originally written for Qukeys.
fixes#806fixes#922fixes#908fixes#985
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
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>
Michael Richters