To make it easier to create custom shortcuts, that do not interfere with system
ones, an old trick is to use many modifiers. To make this easier, Ctrl+Shift+Alt
is commonly abbreviated as "Meh", while Ctrl+Shift+Alt+GUI is often called
"Hyper". To support this, we offer the `Key_Meh` and `Key_Hyper` aliases, along
with `MEH(k)` and `HYPER(k)` to go with them.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We should be using a different variant of the `default_layer()` method to query
the default layer instead of abusing 0xff as a special valie.
Fixes#522.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Add `REDIAL` to `kaleidoscope::ranges`, so the plugin can define `Key_Redial`
itself, and won't need `Redial.key` to be set in the user sketch either. This is
a breaking change, but one that's easy to upgrade to, hence no effort was made
to make it at least partially backwards-compatible.
Fixes#519.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When selecting a new default layer via Focus, we should be moving there too,
because there may be no other way to switch to the new layer, and having to
reboot the keyboard for changes to take effect is not our desired behaviour.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When sending `Key`s, there's no need for an extra separator, because
`send(key.raw)` will send one anyway. Not sending one results in 10 bytes less
PROGMEM used, and plenty of bytes less spent over the wire.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When we use `lookup()`, we're looking up from the cache, not from the active
layer. If the cache gets updated later than we're called, we won't notice. So do
an explicit lookup.
Fixes#507.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Due to the plugin needing a key coordinate -> geometric space mapping, it
depends on the keyboard used. As such, restrict it to the Keyboard.io Model01,
for which the mapping was set up.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the rainbow colors are great, some may want to restrict the colors to a
single hue. For this purpose, the `ripple_hue` property was introduced. It
defaults to `Wavepool.rainbow_hue` (a special value that tells the plugin to use
multiple hues).
Inspired by @bjc's ToyKeeper/Kaleidoscope-LED-Wavepool#8.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Based largely on ToyKeeper/Kaleidoscope-LED-Wavepool#8, this smooths out the hue
transitions, so that the ripple is a nice rainbow, without oddly flashing colors
while cycling through the effect.
Thanks @bjc for the change!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Methods that originate from the `kaleidoscope::Hardware` base class need not be
documented every time they're being overridden. That leads to duplication, and
higher chance of documentation going stale. As such, remove such cases, and rely
on the base class having plenty of documentation instead.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Since all implementations of detachFromHost/attachToHost are the same for all
our current keyboards, move it to the base class as a default.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is basically the old Kaleidoscope-Hardware plugin pulled in, and made into
a base class. The purpose is documentation (#167) mostly. The base class has
default implementations for all methods (most do nothing), and can be overridden
by derived classes. Since the hardware object is always going to be called
through `KeyboardHardware`, which has the exact type of the hardware, we do not
need to use virtual functions. The derived class will just shadow the default
implementations.
All hardware plugins were updated to use this (directly or indirectly). The
resulting compiled binary is the same, but we were able to remove a few
boilerplate lines from here and there.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In general, we want method names to be verbs, because they convey actions. The
`Layer.on()`, `Layer.off()`, etc family of functions weren't like that. It
wasn't immediately obvious that they turn layers on and off.
Furthermore, `Layer.next()` and `Layer.previous()` were even more confusing,
because one could easily think they implied moving to the selected layers, while
in practice, they just activated them.
All of these have new names, that better describe what they do. The old names
are still present, but emit a deprecation warning.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In the original `KeyboardioFirmware`, this was used to store the default keymap
index in EEPROM. When we removed the EEPROM storage, it was meant to be used by
sketches to set a default layer (the minimum layer one can switch to), which was
not nearly as useful. Even worse, the behaviour was complicated to reason about,
and it wasn't used anyway.
For these reasons, it is now deprecated, and will eventually be removed.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
As the name implies, this makes it possible to set all leds to the same color
depending on which layer is the topmost active one.
Fixes#492.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The ATMega32u4 chip Splitography does not have the JTAG interface disabled in
fuses, so we must do so from the firmware. Otherwise PIN_F4 - PIN_F7 would not
be usable for I/O.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To work around an issue on OSX, initalize Serial as the very first thing in
`Kaleidoscope.setup`. This is a - hopefully - temporary workaround, until we can
track down the real issue.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Based on a discussion on Discord, this implements a simple plugin that can
temporarily disable the Windows (GUI) keys.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When I did the GPLv3+ -> GPLv3-only change, and assigned my copyright to
Keyboard.io, some of the plugins were missed. This updates those too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Make it possible to use the plugin for all known Atreus variants: the post-2016
PCB with A* and the FalbaTech handwired one with a Teensy (these two were the
only supported ones until now), the pre-2016 PCB with A*, and the legacy Teensy2
variant.
Fixes#430.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The pin list (and consequently the key layout list) was rearranged in the early
days of the plugin for more optimal scanning code. With -O3 and moving to
`ATMegaKeyboard`, that optimization is no longer relevant. This restores the pin
list and the layout to its original order, the order at which the hardware is
laid out.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Introduce a couple of helper methods that make it easier to work with Focus.
These abstract away the dependency on Serial as a side-effect. The intent is
that all traffic will go through Focus.
Fixes#476.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Improved the ATMega parts of row toggling, similar to how `ATMegaKeyboard` does
it, and separated it from selecting extender rows. This results in a tiny
increase in speed, and better clarity.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of only reporting the state when the timer triggers, report it every
loop, even if it is unchanged.
This is based on a similar change to `ATMegaKeyboard`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Set the previous key state when reporting the state to Kaleidoscope, instead of
on every read. This eliminates a possible chatter bug. Idea taken from a similar
change made to `ATMegaKeyboard`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Based on the change made to `ATMegaKeyboard`, apply the same treatment to the
`ErgoDoxScanner` too, and run debouncing only 3 times per 5ms, which is closer
to what switch manufacturers recommend.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Keys normally only change when switching layers, so instead of going through
every key in every cycle to look for modifiers, do that once, when layers
change (using the new `onLayerChange` event), and store the coordinates of keys
we consider modifiers in an array (currently limited to 16 items).
Then, when we want to highlight them, go over this array only, significantly
reducing the work we need to do. In a typical case, on a full-size keyboard, one
would have eight modifiers and a few layer keys, so instead of going through a
hundred keys, we go through sixteen at most, but usually considerably less.
This fixes#403, at the cost of noticeably higher PROGMEM and RAM use.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of tracking layer changes ourselves, use the new `onLayerChange` event
to do that for us. This makes the code a tiny bit easier to follow.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The intent is to make it easier for plugins to detect layer changes and schedule
work accordingly. There event receives no arguments, the current state can
always be queried with `Layer.getLayerState()`, and if a plugin requires the old
state too, they can track that on their own.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If we wish to support hardware that has LEDs, we should not define the `cRGB`
struct and the `CRGB` macro unconditionally. Define them only if the macro is
undefined. This way any hardware that has LEDs, and still wishes to use
`ATMegaKeyboard` as a base can define the macro prior to including the header.
Such hardware will override the LED functions anyway, so there's nothing else we
need to do to support such a scenario.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Sometimes we'd like to be in control of when reports are sent during macro
playback. This implements a way to achieve that.
Fixes#368.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of guarding the ATMegaKeyboard files with an `#if` that hard-coded which
keyboards are based on the class, guard them with
`KALEIDOSCOPE_WITH_ATMEGA_KEYBOARD`, set by the main hardware headers. Those
headers get included early, and are as such, a perfect way to guard these
things.
This way if we add a new keyboard using the base class, we don't have to modify
the base class itself, and the new hardware plugin can be entirely self-contained.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Since `keyIndex` is pretty much the same for all boards, it makes sense to have
it in `key_indexes.h`. To be able to do that, we need to implement it as a
macro, otherwise `HARDWARE_IMPLEMENTATION` can't be resolved. With a macro, it
is evaluated on call-sites, where the compiler can resolve that symbol.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Whenever calling a function implemented by the class, call it through
`KeyboardHardware`, so they can be overridden.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Both the Atreus and the Planck ports use very similar architecture, lift out the
common parts into a base class.
Signed-off-by: Jesse Vincent <jesse@keyboard.io>
Instead of having a separate function for selecting and unselecting rows, have
only one that toggles them - we only ever want to toggle them anyway. While
there, optimize it slightly, by not toggling `DDRD`: if we set those in `setup`,
they'll remain set, and there's no need to toggle them.
This makes the code cleaner and smaller, at the cost of four bytes of RAM.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In certain cases we need to delay the unicode input sequence, otherwise the host
is unable to process the input properly. Introduce the `.input_delay()`
setter/getter for this purpose. We're defaulting to zero (no delay) nevertheless.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Based on work by Shriramana Sharma (@jamadagni) in
keyboardio/Kaleidoscope-LEDControl#27, this adds an optional `phase_offset`
argument to `breath_computer`. This allows one to have multiple breath effects
active at the same time, at different phases.
To make these synchronized, use `Kaleidoscope.millisAtCycleStart()` instead of
`millis()`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Initially, we were using `uint8_t` as the type for led indexes, which could not
go below zero, so we only needed one half of a bounds check. Since we switched
to a signed int, we need to check the other half of the boundaries: if the index
is below zero.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Based on the work of Shriramana Sharma (@jamadagni) in
keyboardio/Kaleidoscope-OneShot#45, this implements finer stickability controls
for `OneShot`, allowing one to set stickability on a per-key basis. The old
`.double_tap_sticky` and `.double_tap_sticky_layers` properties still work, but
are deprecated.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When calculating `end_time`, explicitly cast `idle_time_limit` to 32 bits,
otherwise the `idle_time_limit * 1000` operation will be done on 16 bits, which
would overflow at about 65 seconds. With the cast, the operation will use all 32
bits, and we avoid the overflow.
Many thanks to @nevd for the report and the help in debugging & testing the fix.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Suggested by `nev` on Discord, this plugin will turn the LEDs off after a
configurable idle time, and back on on the next keypress.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When `LEDControl` is paused, we want to pause not just the LED modes, but *all*
LED operations. The easiest way to do this is to not sync them.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is pretty much the same thing as keyboardio/Kaleidoscope-OneShot#23 by
@jamesnvc, except that it also changes the `isLayerKey()` macro, which was
otherwise unused.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To make the interaction with plugins that work on top of LEDModes (such as
`ActiveModColor`), we need a `refreshAt()` method. For AlphaSquare, we'll return
black when a pixel has timed out, or if a key is not part of the currently lit
symbol.
Fixes#401.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of remembering a key whenever a new one toggles on, remember only when
Redial itself is not held. We keep track of the last pressed key while Redial is
held, though, so we can update the key to redial when we're released ourselves.
This should fix#396.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
A long-long time ago, Kaleidoscope used to call `onKeyswitchEvent` (or rather,
it's then-current incarnation) even when keys were idle. For a number of
plugins, this was a case they didn't want to handle, and bailed out early.
When we changed Kaleidoscope to not call the event handlers for idle keys, these
plugins weren't modified at the same time, and the superfluous check remained,
making the firmware both larger and marginally slower.
Since the event handlers are never called when idle, it is safe to remove these
checks.
Affected plugins are `Leader`, `OneShot`, and `TapDance`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
EscapeOneShot needs to stop bailing out early when a oneshot is pressed (sticky
appears pressed), and continue with its process if there's a sticky oneshot.
This makes stickies cancelable via the EscapeOneShot plugin.
For this to work, OneShot needed an `.isSticky()` method, much like
`.isActive()` and `.isPressed()`.
Fixes#413 and likely addresses part of #408 too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Way back when, in order to fix the issue explained in
keyboardio/Kaleidoscope-OneShot#4, we made it so that keys that interrupt a
OneShot will be masked (unless certain conditions are met). Since then, we
changed how keys are looked up, and the original problem is no longer present.
This makes the masking unnecessary.
Begin unnecessary is good news, because that masking prevented key repeat for
keys on a one-shot layer (even when the OSL key was held).
Fixes#415.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This allows us to do `i < LED_COUNT` comparisons on boards with no LEDs. All
places that did this comparison have been updated to use `int8_t`, as were all
places that use a LED index.
Together with the previous commits, fixes#385.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
LED related functions should be as close to no-op on LED-less hardware as
possible. For this reason, guard all relevant points with an early exit in the
LED-less case.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Intended to make it easier for LED-using code to bail out early, this simple
constant will tell us whether the board has LEDs or if it does not.
Because this will be used regularly, by code not close to the hardware,
`Kaleidoscope.has_leds` is an alias to `KeyboardHardware.has_leds`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In an attempt to move away from magic, global defines, move the `ROWS`, `COLS`,
and `LED_COUNT` defines to the hardware class. Backwards-compatible defines are
provided by `<Kaleidoscope.h>`.
This is just a first step, no users are updated just yet.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
With moving to a monorepo, the plugin will always be compiled, so we want to
guard ourselves, to only compile when building for the ErgoDox. We do this with
an `#ifdef ARDUINO_AVR_ERGODOX` guard.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Hardware-EZ-ErgoDox.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
With moving to a monorepo, the plugin will always be compiled, so we want to
guard ourselves, to only compile when building for the Atreus. We do this with
an `#ifdef ARDUINO_AVR_ATREUS` guard.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/HostOS.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
The `Kaleidoscope/HostOS-select.h` remains in place, for compatibility reasons.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/TypingBreaks.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Unicode.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Syster.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Redial.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LED-ActiveModColor.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Qukeys.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/TapDance.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/SpaceCadet.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/ShapeShifter.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LEDEffects.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This replaces the former `bootAnimation()` method with a plugin that does
something very similar, without locking up the keyboard for the duration of the
animation, and scans the keymap instead of using hard-coded coordinates.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In the Model01 header, we have a set of LED coordinates, based on key
labels (`LED_Q`, `LED_A`, etc). These aren't generally useful, the only user was
the ancient `bootAnimation`. With that gone, lets get rid of these too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This boot animation has not been used for a long time, and chances are, noone
even noticed its here. It's a neat thing, but gets old very fast, and locks up
the keyboard during the animation.
Considering these, lets drop it.
Fixes#366.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Moved all files but `LEDControl.c` and `LEDControl.h` to
`src/kaleidoscope/plugin/LEDControl`, to not pollute the `kaleidoscope/plugin`
directory needlessly, with headers that should not be explicitly included.
Also updated the documentation and the warnings emitted to make it clear that
the use of `LED-Off.h` and `LEDUtils.h` is deprecated in favour of just using
`<Kaleidoscope-LEDControl.h>`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move auxiliary files to `src/kaleidoscope/plugin/MouseKeys` to not pollute the
`kaleidoscope/plugin` directory with headers not meant to be included directly.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Moved most files to `src/kaleidoscope/plugin/LED-AlphaSquare`, leaving only the
main one on the outside. This is to decrease the number of files in
`src/kaleidoscope/plugins` and not pollute the namespace needlessly.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
With Kaleidoscope core's layout rearranged, we should include
`kaleidoscope/macro_helpers.h` instead of `macro_helpers.h`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Merged `EEPROM-Settings-Focus` into `EEPROM-Settings` itself: there's no reason
they should be separate. Also moved the CRC headers to
`kaleidoscope/plugin/EEPROM-Settings/` to not pollute the plugin namespace.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LEDControl.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/MouseKeys.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/NumPad.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/MagicCombo.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/EEPROM-Settings.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LED-Stalker.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LEDEffect-Rainbow.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LEDEffect-Chase.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LEDEffect-Breathe.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LEDEffect-BootGreeting.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Hardware-Model01.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Model01-TestMode.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Macros.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LEDEffect-SolidColor.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LED-AlphaSquare.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Leader.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/GhostInTheFirmware.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/FocusSerial.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
This also merges the former `UPGRADING.md` into `doc/plugin/FocusSerial.md`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Lots of things were already under the `kaleidoscope` namespace, but were in the
"wrong" directory. This big patchset moves everything under `kaleidoscope/`, and
namespaces `Layers_`. There are a few un-namespaced things, but because their
use is so widespread, and they're used so commonly, we don't want to namespace
those (like `handleKeyswitchEvent`), at least not yet.
As a minor side-effect, this moves a few global statics that were once in
`Layers.cpp` into the `Layer_` class itself, for clarity and encapsulation.
Non-namespaced headers that were used outside of Kaleidoscope itself will still
work, but will emit a compile-time warning.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The `FingerprintUSBHost` library isn't the most reliable thing, so instead of
setting false expectations, remove auto-detection instead. This makes the plugin
a whole lost simpler, and depend on one less library.
Fixes#9.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/USB-Quirks.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/TopsyTurvy.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Steno.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/OneShot.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/LED-Palette-Theme.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/HostPowerManagement.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Heatmap.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/FingerPainter.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Escape-OneShot.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/EEPROM-Keymap-Programmer.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/EEPROM-Keymap.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Cycle.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/Colormap.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move the documentation to `doc/plugin/CycleTimeReport.md`, sources under
`src/kaleidoscope/plugin/` (appropriately namespaced). This is in preparation of
merging plugins into a single monorepo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If we have key coordinates set, we don't need to search the keymap, we can just
use the coordinates as-is.
Fixes#10.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The plugin is much less useful without EEPROM storage, even confusing when using
the Focus commands. As such, enable the storage unconditionally. This makes the
`enableEEPROM` method obsolete, so we mark that as deprecated.
Based on, and fixes#12 by Matt Venn <matt@mattvenn.net>.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Several define directives could be replaced by constexpr variable
definitions. This adds type safety with no overhead costs.
Signed-off-by: Max Görner <max@familie-goerner.eu>
When a Focus command changes either the palette, or the theme, call
`LEDControl.refreshAll()` to repaint the LEDs. This way we don't have to force a
repaint some other way, and changes take effect immediately, as they should.
Fixes#8.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If we received a `colormap.map` command via Focus, refresh the colormap. It
might be in response to a query (ie, no change), but this should happen
infrequently enough for us to don't care about that inefficiency.
On the other hand, refreshing on `colormap.map` means that if the colors do
change, that's immediately reflected on the keyboard. Right now, if we change
the colormap, it doesn't activate until we change layers, cycle LED themes, or
otherwise force a refresh.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of a low-level interface where one has to set the EEPROM-stored layers
and the lookup method separately, introduce a `setup` method that combines the
two in a much easier to grasp interface. It takes a layer number, and an
optional mode, and sets things up accordingly.
With this new setup procedure comes a new way of how the plugin works: instead
of being able to override the keymap in EEPROM, we extend it (or use a custom
implementation, for advanced use-cases). The default layer can still be set via
Focus, thus effectively overriding the keymap in PROGMEM. To better support
this, a new Focus command is introduced too: `keymap.roLayers`, which returns
the number of layers in PROGMEM.
The `keymap.transfer` Focus command is removed, because it can be done much more
reliably from the host side, building on top of `keymap.map`.
The rest of the lower-level interface is still there, though undocumented, for
advanced use-cases the new simplified setup does not fit.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
With upcoming EEPROMKeymap changes, saving the default layer will become an
important part of the keyboard settings. The new `default_layer` method provides
a way to set it programmatically, while the `settings.defaultLayer` Focus
command allows the user to set it via Focus.
The default layer - if set - is activated when the settings are sealed, either
directly or automatically.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This removes the `magic` field from the beginning of the header. It was
originally meant to signal if the EEPROM we're dealing with is new, or if it has
been set up with `EEPROMSettings` before. But as `EEPROMSettings` is pretty much
the only way we deal with EEPROM, there's not much need for that.
With the removal, we do need a way to update the CRC bits on first use, so we
use the `version` field instead: if it is `0xff`, we update the CRC, and
consider the settings valid. This means that until the version is set, the
EEPROM layout is considered flexible, and verification is essentially disabled.
Once the version is set, we can validate.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While there, drop the `keymap.layer` command, which was a workaround to a
Chrysalis bug fixed since.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Migrate from the old `Focus` API to `onFocusEvent` provided by Kaleidoscope
core.
As a side-effect, remove the `colormap.layer` command, which was a workaround
for a Chrysalis bug fixed since.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Migrate from the older `Focus` API to `onFocusEvent` provided by Kaleidoscope.
As a side-effect, this drops the per-layer focus command support, as that was a
workaround for a Chrysalis bug fixed since.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is not directly used by Kaleidoscope itself, but we provide the hook from
here, for the sake of convenience. It will be used by plugins such as
`Kaleidoscope-FocusSerial`, in much the same way as Focus hooks were used
previously.
This does change the architecture a bit, and the `FOCUS_HOOK_KALEIDOSCOPE` focus
hook previously provided by Kaleidoscope itself is something that no longer
belongs to core, but rather to a plugin. As such, the hook is removed as part of
this patch.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
`max_layers` is a method, so comparing to that would be integer<->pointer
comparison. We want to compare to `max_layers_`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If we're looking up a key from `PROGMEM`, only do that if the layer in question
is smaller than `layer_count`. Doing otherwise would read garbage from `PROGMEM`
in case we try to read from a layer higher than what we have in there. This can
happen if we have more layers in `EEPROM` than in `PROGMEM`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To make it easier to use the plugin, pull in `EEPROMSettings` by default, and
explicitly call its `onSetup` (it is safe to do so), so user sketches don't have
to if they don't use `EEPROMSettings` directly. Also set `Layer.getKey` to
`EEPROMKeymap.getKeyOverride` to provide a sensible default.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If `EEPROMSettings.seal()` wasn't explicitly called, seal the layout in
`beforeEachCycle()`. On the flip side, this makes user sketches simpler, because
they don't have to seal explicitly. This is done at the cost of an if check each
cycle.
In the long run, EEPROM layout management will be moving out of this plugin, so
this check will be eventually dropped too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
These two lines went in by mistake earlier, they were meant for local
debugging only. As such, having them in the plugin is a bug, easily
squashed by removing them.
Signed-off-by: Csilla Nagyné Martinák <csilla@csillger.hu>
Rearranged the columns so we can do some bit shifting and OR-ing magic instead
of manually picking bits from various pins.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In the Topsy case, pre-calculate `mapped_key.raw` for both branches, and only
modify its flags in the unishfted branch. This saves us about a dozen bytes of
PROGMEM.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We do not need to track which shift is pressed, so lets use a bool instead of a
bitfield. Makes the shift checking code smaller too!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Like in the unshifted case, avoid injecting keys, and fiddle with `mapped_key`
instead. This allows us to get rid of the `TOPSYTURVY` bitflag.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is to avoid the case where chording a Topsy and a non-Topsy key would
result in both being repeated very fast. This happened because each cycle we
sent two reports: one for the Topsy key, one for the others. This didn't allow
the host's normal repeating behaviour to kick in, and instead, resulted in both
keys being input very fast.
Fixes#5.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We're not calling `onKeyswitchEvent` in the idle cases anymore, drop the check
for a few bytes saved.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
TopsyTurvy derived from `KaleidoscopePlugin`, which was part of the V1 plugin
API, and has been recently removed. Use `kaleidoscope::Plugin` instead, which is
its replacement.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
ShapeShifter derived from `KaleidoscopePlugin`, which was part of the V1 plugin
API, and has been recently removed. Use `kaleidoscope::Plugin` instead, which is
its replacement.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
After talking with Jesse, this changes the license to GPLv3 (only), where
appropriate, and adds copyright headers to all files that were missing them.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Scheduled for removal on 2018-08-20, this drops the V1 API and all deprecation
messages. We only keep one message, that errors out in case
`KALEIDOSCOPE_ENABLE_V1_PLUGIN_API` is set. Also drops `Consumer_SNapshot`,
which was a typo'd name.
`UPGRADING.md` updated accordingly.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is just to clarify to anyone who may be reading the sources as to why B00100000 is missing from the flags defs. Not a big deal but I thought it would be useful…
This, along with the change
keyboardio/Kaleidoscope-HIDAdaptor-KeyboardioHID@a4368f13e7a1b58e, makes
it so a rollover from a key with a mod flag applied to one without will
not result in the flag from the modified key affecting the next keypress.
The breathe function is somewhat costly and is found to cause drag in
mouse movements. This commit seeks to fix this problem.
It is observed that the function doesn't change output value for every
input value. It only causes the output brightness to increase by 128
units (from 80 to 208) over 2048 ms (the half-period). This means 1 unit
for 16 ms. But a brightness change of 1 unit doesn't mean much visually
especially considering persistence of vision. A refresh rate of 20 per
second ie 50 ms between LED updates is found to be sufficient to avoid
the drag effect while maintaining smoothness in brightness changes.
While we do clear the report every cycle, similar to how key release events are
explicitly removed from the report, mouse movements should get removed too. This
makes it possible to use them in macros reliably, without surprising results (an
extra report sent at the end of the macro).
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This mirrors `moveMouse()`, and the intent is to use it when releasing a mouse
key outside of the main event loop (such as during a macro).
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When using `Kaleidoscope.use()` and the V1 API is disabled, we want to display
an error. The current method of doing that is not reliable, it sometimes works,
sometimes will error out even when not using `Kaleidoscope.use()`. To fix this,
delay the initialisation of `.use()`, so it only evaluates when used, and thus,
only fails with a descriptive error in that case.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Override the copy constructor of `combo_t`, so that we can display an error when
initializing using the old-style API.
Fixes#8.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In preparation for the sunset of the V1 API, when using the V2 API only, give a
nice error message on `Kaleidoscope.use()`, instead of simply not defining it.
This makes the upgrade path a little easier.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When a key was released, we were failing to send the release event explicitly. For most
plugins, this didn't matter, but it was causing a problem for Leader, which acts on
release events. By returning `EVENT_CONSUMED` instead of `OK`, we were stopping the
release event from getting through to Leader, and thus a qukey with a Leader key as its
primary keycode would fail.
When the V1 plugin API is enabled, we need to override `onSetup`, to not call
`setup()` twice: once via the v2 default `onSetup`, and once via the legacy API.
Take special attention to call `LEDControl.mode_add`, so that the effect does
register as a LED mode.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When using the V1 compatibility layer, in the `onSetup()` method, we need to
call `LEDControl.mode_add()`, otherwise the mode does not register, and will not
function.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If we do not clear `should_cancel_` there, it remains set indefinitely (until it
gets unset for some other reason, like interrupting a non-sticky OneShot). If it
is set, we can't enter sticky mode.
So clear it when canceling stickiness with a third tap, just like we clear it in
`afterEachCycle`.
Fixes#34.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Unfortunately, the way we reported the use of an old-style API also triggered
when not using it. Change that to only trigger when we DO use the old API, by
marking the `combo_t` constructor private.
Unfortunately, this does not allow us to use a custom error message.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of manually counting set bits, use gcc's `__builtin_popcount()` for a -
supposedly - more efficient count.
Also initialize the counter to zero, while there.
Fixes#11.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of iterating through all the bits, use `__builtin_popcountl()`, provided
by gcc, which should be considerably more efficient.
Fixes#27.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
`Consumer_SNapshot` really should have been `Consumer_Snapshot`, so lets fix it.
However, the typo'd name is left in place as an alias, in order to not break any
existing user code, however unlikely the use of this key is.
Sadly, we can't easily add a deprecation warning, because key_defs.h, which
defines `Key`, depends on `key_defs_consumerctl.h`, so we'd end up with a
circular dependency if we tried to add a deprecation.
Fixes#339.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
As per UPGRADE.md, remove `Kaleidoscope.setup(KEYMAP_SIZE)`,
`event_handler_hook_use`, `loop_hook_use`, `USE_PLUGINS`, `MOMENTARY_OFFSET`,
`key_was_pressed`, `key_is_pressed`, `key_toggled_on`, and `key_toggled_off`.
These were deprecated between July and October 2017, and have been marked for
deletion for over a month.
Also updated UPGRADE.md, moving the section about these to a new, "deprecated
and removed" section.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When using the old API, fail with a helpful error message that points to
`UPGRADING.md`, which explains in simple detail the migration process.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The old `RxCy` macros were recently changed to be key indexes instead of
per-hand bit indexes, and `KeyboardHardware.isKeyswitchPressed()` and
`KeyboardHardware.pressedKeyswitchCount()` were introduced as a way to peek into
the keyswitch state. This little change migrates TestMode to use them.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using a list of left/right-hand states and an overrideable global
callback, use a map of action and key-list pairs. This makes the plugin much
more portable, does not require any hardware-specific knowledge within the
plugin, and does not require us to treat the hands separately.
This in turn, results in a friendlier user interface, at the cost of limiting
the maximum length of a combination to five keys. A small price to pay.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of `getKeyswitchStateAtPosition`, which is long, unintuitive and feels
wrong too, introduce `isKeyswitchPressed`, shorter, better, more
reasonable (because it returns a bool - we support only two states anyway!).
Additionally, add `pressedKeyswitchCount()`, which returns the number of key
switches pressed.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of `getKeyswitchStateAtPosition`, which is long, unintuitive and feels
wrong too, introduce `isKeyswitchPressed`, shorter, better, more
reasonable (because it returns a bool - we support only two states anyway!).
Additionally, add `pressedKeyswitchCount()`, which returns the number of key
switches pressed.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is sufficiently low-level that it is OK to use `KeyboardHardware` for it.
It's not a HID thing, either.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move `KEY_INDEX` here, and turn it into a `constexpr` function, `keyIndex`, and
convert the `RxCy` macros to constexpr values instead.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To allow the hardware plugin to use a more efficient way of representing the
index (if need be), and to be able to turn it into a constexpr, move it to the
hardware plugin.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To be used by the hardware implementations, `KEY_INDEX` tells us the index of a
key, from which we can figure out the row and column as needed. The index starts
at one, so that plugins that work with a list of key indexes can use zero as a
sentinel. This is important, because when we initialize arrays with fewer
elements than the declared array size, the remaining elements will be zero. We
can use this to avoid having to explicitly add a sentinel in user-facing code.
Additionally, we add `getKeyswitchStateAtPosition` to the HID facade. See its
documentation in `Kaleidoscope-Hardware`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Implement `getKeyswitchStateAtPosition`, a hardware-agnostic way to peek into
the keyswitch state. Also transition the `RxCy` macros to `KEY_INDEX`, to make
it easier for hardware with more keys than 64 to implement them, and to make
their values unique across a keyboard, not just across a keyboard half.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of only having an ifdef in the body of deprecated methods, and leaving
it up to the compiler to optimize out the empty & unused, explicitly wrap the
declaration of them within an ifdef too. This will make it easier to remove
everything V1 at a later point, and we're not at the mercy of the compiler,
either.
Fixes#327.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We do not want user code having to deal with KeyboardHardware, so wrap
.detachFromHost and .attachToHost ourselves.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
These functions can be used to detach from the host, then re-attach, possibly
with different properties, without having to reboot the device.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Having it at the brightest uses too much power, and may result in power use
surges when switching between LED modes and NumPad, which in turn can force the
operating system to disable the whole device. To avoid this, lower the
brightness to 160, a carefull tuned value, also used by the `solidRed` mode in
the factory firmware.
Fixes#9.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The multiplication by 99 can overflow an int8_t depending on whether the
expression is coerced to a regular-sized int (based on the 99 literal).
Just to be safe, perform a cast to int16_t in case the coercion does not
happen.
Previously, diagonal movements were not reduced in the two axes,
resulting in movement that was too quick. This commit divides diagonal
movements by sqrt(2) / 2 to correct the movement speed.
The net result is that diagonal movement should feel smoother and speed
more as expected.
This removes WakeupKeyboard, because a similar feature was integrated into
BootKeyboard itself, rendering it useless.
See keyboardio/KeyboardioHID#35 for an explanation of the whole situation.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of repeating the same cRGB reading code in three places, use the
recently introduced Focus.readColor() function. This both makes the code
cleaner, and more than 50 bytes smaller too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using a lambda (which is not constexpr in C++11), use a temporary,
anonymous struct instance to wrap the `static_assert`, which is constexpr in
C++11.
Fixeskeyboardio/Model01-Firmware#53. Thanks to @noseglasses for finding the
cause, and explaining the fix!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Many plugins use timers, and most of them will call `millis()`, which isn't
wrong, but isn't the most efficient either. While `millis()` isn't terribly
expensive, it's not cheap either. For most cases, we do not need an exact timer,
and one updated once per cycle is enough - which is what `.millisAtCycleStart()`
is. Having a timer that is consistent throughout the whole cycle may also be
beneficial.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of running `scanMatrix` whenever we get there, use Timer1 to set a
consistent period. This does not mean we'll run every time the timer is up, but
we will run at consistent intervals.
Fixes#6.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This adds a very simple debouncing algorithm for debouncing. It works by making
sure a key is not changing state more than a configurable amount of cycles.
Defaults to five cycles for now.
Fixes#1.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The global `ErgoDox` symbol should be a shortcut, an alias, to KeyboardHardware.
When using ErgoDox-specific functionality, `ErgoDox.someMethod()` is much
clearer about that than `KeyboardHardware.someMethod()` would be.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The member functions of the union now take all arguments const, meaning
that it is not possible to modify this value somehow. This reduces the
chance of subtle bugs and widens the contexts in which these member
functions can be used.
Furthermore, one signature took a `Key' by value while all functions
take `Key' by reference. For the sake of consistency, this was adapted
to.
Making the member functions of Key `const' explicitly flags that they
will not change the union. This will allow to use Key in const contexts.
Adding the `constexpr' specifier to the function makes it possible to
rely on the results at compile time. This puts some kind of restrictions
on the function, especially when using C++11 and not a newer standard,
but these restrictions were already fulfilled, so this seems to be safe.
By far the most common deprecation will be the event handler and loop hook
deprecation. Make them less scary, and point out that unless one's a developer,
they likely need not care.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Moving the deprecation messages to a separate header, and adding a few helpers
allow us to write much more detailed deprecation messages, without needlessly
making the code look incredibly messy.
This also updates most of the deprecation messages to be much more helpful, and
provide hints at how to fix the warnings produced by them.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Due to the plugin API redesign, plugins that migrate may want to ensure they are
compiled against a recent enough Kaleidoscope. Others may opt to provide
separate implementations for each version. For this to work, we need to bump the
API version.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Fixed a conditional so that the event handlers of old-style plugins will be
called. Without this, they don't, and old-style plugins that install event
handlers, would not work.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
With this redesign, we introduce a new way to create plugins, which is easier to
extend with new hook points, provides a better interface, uses less memory, less
program space, and is a tiny bit faster too.
It all begins with `kaleidoscope::Plugin` being the base class, which provides
the hook methods plugins can implement. Plugins should be declared with
`KALEIDOSCOPE_INIT_PLUGINS` instead of `Kaleidoscope.use()`. Behind this macro
is a bit of magic (see the in-code documentation) that allows us to unroll the
hook method calls, avoid vtables, and so on. It creates an override for
`kaleidoscope::Hooks::*` methods, each of which will call the respective methods
of each initialized plugin.
With the new API come new names: all of the methods plugins can implement
received new, more descriptive names that all follow a similar pattern.
The old (dubbed V1) API still remains in place, although deprecated. One can
turn it off by setting the `KALEIDOSCOPE_ENABLE_V1_PLUGIN_API` define to zero,
while compiling the firmware.
This work is based on #276, written by @noseglasses. @obra and @algernon did
some cleaning up and applied a little naming treatment.
Signed-off-by: noseglasses <shinynoseglasses@gmail.com>
Signed-off-by: Jesse Vincent <jesse@keyboard.io>
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This commit includes the resetMap method which is used to start the heatmap from 0. I also use it as a workaround for my map starting up with an "infinitely hot" key
Any event with the `INJECTED` flag set is now ignored. This is necessary because OneShot
now sends events with valid `row` & `col` values when it calls `handleKeyswitchEvent()`,
and we need to make sure those events don't get enqueued in the case of a qukey whose
primary keycode value is a OSM key, followed by a key that is meant to be modified by that
key. Fixes#40.
Use a timeout calculation method that is not affected by overflow, and also
requires 16 bits less.
This likely fixes#8.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Ticks depend on the speed of the main loop, and as such, are not a reliable way
to time animations. For this reason, use proper timers instead.
The update delay is set to 40ms, which appears to be a slow, relaxing animation,
and should be roughly in the ballpark the tick-based timing was, before speeding
up the main loop considerably.
Fixes#3.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Sometimes one wants a longer timeout, also wants the sticky behaviour on
double-tap, but would like to use a shorter timeout for the sticky behaviour.
The new `double_tap_timeout` property accomplishes just this.
Defaults to using `time_out`, for backwards compatibility.
Fixes#30.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When we activate a OneShot key, use the coordinates of the (last) physical key
that triggered it. This is done by keeping an array of positions for each
possible OneShot key. While this costs us 16 bytes of RAM and a bit of code, the
benefit is that plugins ordered after OneShot will know where OneShot was
triggered from.
Fixes#13.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This warp mode is similar to the navigation provided by some speech
recognition software. A 9-cell grid may provide more precision and
efficiency than the existing 4-cell warp mode. This adds some extra
key definitions to support the additional sectors and enables a user
to switch the grid size:
MouseKeys.setWarpGridSize(MOUSE_WARP_GRID_3X3);
Signed-off-by: Cy Rossignol <cy@rossignols.me>
With the previous algorithm, once every 65 seconds, there would be a significant jump in
the brightness of the "breathing" LEDs as the 16-bit value recorded from `millis()`
overflowed. Instead of dividing by 12, I changed it to a bit shift (4 bits; equivalent to
division by 16), so when the integer overflow occurs, the next value is what it should be.
This is a somewhat unwieldy fix for all the out of bounds (attempted) array addressing at
both ends. When `pos` goes out of bounds in either direction, the test is the same because
it's an unsigned integer. However, after the change of direction, the trailing LED will
still be out of bounds, so we check that every time we call `setCrgbAt()` for `pos2`.
It's rather ugly, but it does ensure that we don't call `setCrgbAt()` with an
out-of-bounds address.
Before this change, we couldn't use the full functionality of the plugin's
warp feature to drag an item (by holding down a mouse button key). The
plugin would reset the warp state during each scan cycle, so we could
only warp the pointer to a cell in the top-level grid. This fix enables
warping repeatedly into sub-cells while holding a mouse button.
This prevents an insignificant error, but it is more correct to handle the integer
overflow instead of ignoring it. I've also changed syncTimer from a 32-bit to 16-bit
integer, which results in a smaller code size, and changed the computation of the timeout
slightly, so the LED update interval is always the same (we add `syncDelay` to the
previous update's start time, not it's end time), rather than varying based on when
LEDControl's `loopHook()` function is called relative to the last timeout.
There already exist 2 rainbow LED effects, this adds a third, using
the LED-Stalker effect.
When you press a key, the LED on that key will cycle through all the
colors of the rainbow, independent of the colors of other keys.
I had failed to check that the queue length was non-zero before checking release delay
timeouts, causing reading past the end of the `key_queue_` array an repeatedly sending
essentially random input to the host.
In the process of fixing that bug, I realized that I was also assuming that layer changes
weren't happening earlier in the queue and checking whether or not a key is a qukey when
it wasn't the head of the queue. Now we only enact a release delay when `flushKey()` is
called, and always call `setQukeyState()` when enqueuing new keys so that we can
distinguish between keys that should be immediately flushed in the primary state, and ones
that should have keypresses delayed.
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.
Since keyboardio/Kaleidoscope-Hardware-Model01#23 we do not call
`handleKeyswitchEvent` for keys that are idle. Document this in the comments.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When a keyswitch has been off in the previous cycle and is still off now, do not
call `handleKeyswitchEvent` on it. As an extension, when the whole column is
idle, skip the whole thing.
In practice, handling fully idle keys is not useful. There are many plugins
which explicitly look for this case and return early, because it isn't an
interesting event. As such, not calling the event handler in this case makes
sense, as we save not only a few needless checks in plugins, but our performance
improves greatly too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In `actOnMatrixScan`, there is no need to use temporary variables, we can just
pass the data directly to `actOnHalfRow`, and doing so makes the code easier to
follow.
In `actOnHalfRow`, we can further optimize things if instead of reading the Nth
bit, we always read the first, and shift the byte at the end.
All of these optimizations were done by @obra, I just wrote the commit message.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When there are no state changes, and no keys pressed on a row, instead of
iterating through a byte bit-by-bit, just fire idle events without checking the
bits. In all other cases, do the bit-walking like we did before.
The reason this is useful is because bit-walking is costly, and slow. If we can
avoid that, we win quite a lot of performance. Since rows being idle is the most
common case on a keyboard, this is a huge net win. Even in the worst case, where
no rows are idle, this is just one byte comparison and a branch slower than our
previous implementation.
As part of this optimization, `actOnHalfRow` was lifted out into its own
function, to reduce code duplication.
Many thanks to @gedankenexperimenter for the original idea!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
I made a bunch of changes to improve SpaceCadet for the better.
1. I resolved issue #9 ( https://github.com/keyboardio/Kaleidoscope-SpaceCadet/issues/9 ) to support mappings on Alt keys under Windows. This change in behavior means that we don't send the initial key value (the key with a mapping) until we hit the timeout (if held) or if we hit another key in combination in the mean time (to keep modifiers working as expected in combination with other keys). This means that when you place a mapping on Alt, we don't send Alt if you are just tapping -- we only send the other key value. This prevents Alt capturing the menu bar in Windows apps, and probably means we can better support SpaceCadet on non-modifier keys.
2. I added support for enabling, disabling, and determining if SpaceCadet is currently enabled. This allows other plugins and macros to better interact with SpaceCadet, and allows us to temporarily disable the behavior if that's desired.
3. I added two new virtual Key entries for placing on the user's keymap. One key disables SpaceCadet, and the other key enables SpaceCadet.
I also updated the README.md with all of the relevant changes.
It seems that if we inject the release of the mapped modifier key before injecting the press of the alternate key, we avoid the need to call `hid::sendKeyboardReport`, which in turn fixes#7. Which is nice.
Closes#7
It seems that if we inject the release of the mapped modifier key before injecting the press of the alternate key, we avoid the need to call `hid::sendKeyboardReport`, which in turn fixes#7. Which is nice.
Closes#7
Allow user to specify custom boot greeting key by Key_* or by specific row and column. Add ability to define custom duration of boot greet breathing effect, and add ability to change color hue of breathing effect. Finally, rework logic that happens when plugin is loaded to allow all user custom settings to be properly read and applied as expected.
add hue to the header
Updated readme to support new features
astyle + change to allow custom settings
In `hexToKeysWithNumpad`, have a default case, a pointless one, because we never
take that branch, but it silences a warning.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This avoids the OS being stuck with Numlock on, which leaves the LED on
if other keyboard are attached, and breaks FVWM.
See keyboardio/Model01-Firmware#42
This restricts the data type of the enum to uint16_t, so if anyone ever adds enough values
to it to overflow the 16 bits that are available in the Key structure, even if they do it
without an assignment (e.g. `TOO_BIG_ENUM = 0x10000`), it will result in a compilation
error instead of runtime errors.
These macros were copied and pasted, I'm guessing from the USB HID Usage Tables document,
where this keycode is identified with a parenthetical, unlike all of the others around it:
`AC Download (Save Target As)`. When automatically converted into a preprocessor macro, it
gets a trailing underscore and an argument, which is not what we want.
This change won't actually fix anything that's currently broken, but it might matter
someday.
Reset the bad key bitfields each time a test is started, so that each test starts from a clean slate. Without this, it was confusing to restart the test and get an ever-increasing number of keys to appear bad immediately.
Store any macros key events and play them after the event handler pass has finished, so we
don't have a problem when holding other keys that are handled after the macro key in a
pass. This fixes the problem where held modifiers wouldn't be applied to macros, and also
fast repeating of printing characters.
This change does introduce a limit (default: 8) on the number of concurrent macros that
can be played.
We are moving towards including the Adaptor from the Hardware library, so we
need not pull them in from user sketches (or from core).
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of pulling it in from the user sketch, do so from the hardware plugin.
The hardware and the adaptor are in close relationship anyway, and with
tweakable knobs, we do not need to use a different adaptor library in advanced
cases, either.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
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
Instead of implementing the HID adaptors within Kaleidoscope, provide an API
only (by marking the symbols `extern`). For the sake of backwards compatibility,
pull in `Kaleidoscope-HIDAdaptor-KeyboardioHID`, a new shim library implementing
the status quo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using `Keyboard.begin` directly, use
`kaleidoscope::hid::initializeKeyboard`. While there, also initialize
`ConsumerControl` and `SystemControl` the same way.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Use `static_assert` instead of `#error` to report an API mismatch, resulting in
a much more informative error message.
Thanks to @cdisselkoen for the request, and @noseglasses for the `static_assert`
idea!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
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.
As we guarantee backwards compatibility throughout a major version, it helps if
we have that version available, so plugins / sketches can check if they are
compatible, and issue a helpful error if they are not. As further convenience,
defining `KALEIDOSCOPE_REQUIRED_API_VERSION` before including `Kaleidoscope.h`
will result in a check being done by Kaleidoscope, and an error printed if it
does not match the API shipped.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
As this is a generic plugin, for keyboards that do not have LEDs, don't tie it
to LEDControl, and don't provide a `toggleLEDs` method. Instead, show an example
how to achieve the same thing from the sketch.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Gergely Nagy
Jesse Vincent
Jesse Vincent
kriber
Shriramana Sharma
Gergely Nagy
Michael Richters
Michael Sloan
Max Görner
Csilla Nagyné Martinák
matt venn
Ben Gardiner
Gergely Nagy
Brian Cully
Daniele Tamino
Jack Zhou
Aaron Christianson
Max Görner
noseglasses
UniversalTimeCodeGit
Ryan Anderson
Cy Rossignol
Toon Claes
Marty Gentillon
Ben Gemperline
Piers Cawley
Maxime de Roucy
Evan Danaher
tobymiller1
noseglasses
Toby Miller
tazlor
Iliana Weller
Nate Soares
Florian Fleissner
James N. V. Cash
Selene Scriven