While not complete yet, this is a stab at documenting the new device APIs. There
are parts still missing, but pointers are there to the headers which show the
API.
`UPGRADING.md` and `NEWS.md` have also been updated to mention these.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The new device APIs were built on top of composition (instead of inheritance,
like the former one). At the highest level, we have `kaleidoscope::device::Base`
and `kaleidoscope::device::BaseProps`. The latter is a set of overrideable
properties, components that make up the device: the key scanner, LEDs, MCU, and
so on.
Many components - like the key scanner and LEDs - also come in a similar setup:
the base class and properties, because this allows us to make them fairly
efficient templates.
All of the existing devices have been ported to the new APIs. While the old
`Hardware` base class remains - for now, and deprecated - it is not guaranteed
to work.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of having to define `HARDWARE_IMPLEMENTATION` to the class name of the
device, and define `KeyboardHardware` from within the plugin, let all devices
set `kaleidoscope::Device` to their own class via a typedef. Furthermore,
instead of `KeyboardHardware`, use `Kaleidoscope.device()` instead. This makes
device plugins a little bit simpler, and our naming more consistent.
Because some parts of the firmware need to access the device object before the
`Kaleidoscope` object is available, we can't make it a member of that. For this
reason, the device object is `kaleidoscope_internal::device`, and
`Kaleidoscope.device()` wraps it. In general, the wrapper should be used. But if
access to the device is required before `Kaleidoscope` is available, then that's
also available.
The `Kaleidoscope` object grew a few more wrappers: `storage()` and
`serialPort()`, so that one doesn't need to use `Kaleidoscope.device()`
directly, but can use the wrappers, which are noticably shorter to write.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In preparation for making Serial access configurable on a per-board basis,
introduce `KeyboardHardware.serialPort()`, which - for the time being - returns
the Serial object.
All users of Serial have been updated to use the new API.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of directly accessing the EEPROM, do so through
`KeyboardHardware.storage()`, which - for the time being - is a function that
simply returns the `EEPROM` object.
All plugins that were using EEPROM directly were updated, and so was the
EEPROM-Settings documentation.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This implements a new plugin for Dynamic (EEPROM-stored) macros. Unlike the
Macros plugin, these macros are stored in EEPROM, and can't run custom code,
only the steps outlined in the Macros documentation.
The plugin provides two Focus commands (`macros.map` and `macros.trigger`) to
get or set the dynamic macros, and to trigger one without having to place them
on the keymap.
Fixes#370.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This introduces two new macro action steps: `MACRO_ACTION_STEP_TAP_SEQUENCE`,
and `MACRO_ACTION_STEP_TAP_CODE_SEQUENCE`. Both of these will tap everything
that follows up to a terminating zero (or in case of the first, double zeroes).
The purpose of these new steps is to allow one to store longer sequences of
tapped input in a more compact manner, without having to prefix each step with
an action.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is a complete rewrite of Qukeys, in order to implement several improvements
and new features:
- A new KeyAddrEventQueue class has been introduced, in order to store both key
press and release events in the queue.
- The direct dependence on KeyboardioHID is removed by only flushing one event
from the queue per cycle.
- The array of Qukey objects is now stored in PROGMEM instead of SRAM, and is
configured via an array reference template function in order to automatically
ensure the count will be correct.
- There is a new algorithm for determining which state a qukey will collapse
into in the case of rollover from qukey to another key, which should reduce
the rate of errors for "sloppy" typists.
- A Qukey with a primary key value that is a modifier (including layer shift
keys) is treated like a SpaceCadet key, with different semantics. The
alternate (non-modifier) key value is only used if the SpaceCadet key is
pressed and released on its own, without rolling over to any other key.
- The code is generally simpler and easier to understand, with better inline
comments explaining how it all works.
Fixes#626.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Some systems (I've confirmed this on an iMac and a MacBook Escape) have a long delay after
the host begins to "sleep" and the keyboard responding to the HostPowerManagement
plugin (i.e. turning off LEDs).
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
We want to be able to notice when the layout of the EEPROM *settings*
changed (which the CRC does not cover). For this reason, we're repurposing the
existing version setting, which wasn't widely used: it is now internal.
We use the version to determine whether the EEPROM has been written to yet, or
if it is uninitialized. This helps us make sure we're starting up with sensible
defaults.
Fixes#559, and fixes#558.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of having a single `keymap.map` Focus command that tries to be smart
about what layers it presents, we should have two separate commands: one to
query the defaults (PROGMEM), and one to get/set the custom keymap (EEPROM).
This makes `keymap.map` and `keymap.roLayers` obsolete, and they're now removed.
Furthermore, having to specify whether the EEPROM keymap extends the built-in
one or not proved to be unflexible. So we re-purposed the highest bit of the
first EEPROM byte, to signal whether we should use EEPROM layers only or not.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The google style allows all_lowercase names for things that are like accessors and mutators, but does not require it. I find that in our codebase, it just makes things look inconsistent
Signed-off-by: Jesse Vincent <jesse@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>
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>
The examples were recently reorganized, but the documentation was not updated,
so some of them were pointing to dangling, obsolete places. This updates them
all to point to the correct locations.
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>
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>
The ErgoDox typically uses a Teensy, and the Atreus has the option to as well.
In both cases, the flashing procedure (whether through the IDE or CLI) will
require the `teensy_loader_cli` tool installed.
Fixes#479.
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>
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>
When merging into the monorepo, all documentation links were updated to point at
the new documentation locations. Even those where the plugin wasn't merged, such
as `Focus` (`FocusSerial` was). Restore the link, so it points where it needs to.
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>
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 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>
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>
Gergely Nagy
josborne777
Gergely Nagy
Michael Richters
tiltowait
Jesse Vincent
ash lea
Scott Perry
Jesse Vincent
Brian Almeida
kriber