When there are different input methods available on Linux (Chinese, Japanese,
etc), using the numpad is more reliable than the number row. As both work,
rather than making it configurable, just switch to numpad on Linux.
Fixes#1064.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To account for non-qwerty host-side layouts, we want to be able to easily set
the last part of the sequence used to start Unicode input on Linux. The newly
introduced `Unicode.setLinuxKey(Key_S)` function does just that.
Fixes#1063.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To allow us to use any other HID than KeyboardioHID, the base device _must_ use
something else (practically, the Base HID), otherwise we'll get a compile error
when building on a platform that KeyboardioHID does not support, even if we do
not use KeyboardioHID. We get that error, because the base class references it
anyway.
As such, lets use the base HID as default, and adjust all users of KeyboardioHID
to explicitly set that: Virtual, Dygma Raise, and ATmega32U4Keyboard. Everything
else derives from the last one, so they're covered with just the change to
ATmega32U4Keyboard.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If multiple events are processed in a single cycle, we want a OneShot key whose
release is triggered by the first one to only affect that key, and not
subsequent ones. For example, if we tap `OSM(LeftShift)`, then `TD(0)`, then
`Key_X`, the OneShot shift should only apply to the output of the TapDance key,
not the `x`.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
SpaceCadet now has three "modes": on, off, and on with no delay. In "no-delay"
mode, when a SpaceCadet key is pressed, its primary (modifier) key value is sent
immediately to the host, and if it is released before timing out, that value is
then replaced by the configured "tap" value of the key.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Switch from `bool` to `enum` in preparation for a third mode of SpaceCadet
functionality, where the modifier becomes active immediately when the key is
pressed, rather than waiting for the key to resolve into the "hold" or "tap"
state.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
If `ActiveModColorEffect` was registered ahead of `OneShot` in
`KALEIDOSCOPE_INIT_PLUGINS()`, `OSM()` and `OSL()` keys would light up in the
OneShot "sticky" state, not in the "held" or "one-shot" states. This happened
because OneShot changes the `event.key` value to the corresponding base
key (modifier or layer shift), but if ActiveModColor had already processed that
key event, it wouldn't recognize the key as a modifier/layer shift key, and
would therefore ignore it.
This change makes ActiveModColor also recognize OneShot keys as modifier/layer
shift keys.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Its utility is very limited now that `macroAction()` only gets called when a
Macros key toggles on or off, and it uses a symbol that breaks an abstraction
barrier (a local variable of the `macroAction()` function).
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This makes it unnecessary to include `Arduino.h` (or `stdint.h`, or some other
header that includes it) before including Kaleidoscope-Ranges.h.
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>
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 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>
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>
Gergely Nagy
Michael Richters
Gergely Nagy
Jesse Vincent