This reverts commit c917acb8a1, because that
introduced breaking changes, and we want to address the problem in a different
way instead.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This introduces a new plugin - `FlashHelper` - to aid with firmware-assisted
flashing. During the flashing process, this plugin can temporarily disable the
`Prog` key.
Addresses the firmware part of keyboardio/Chrysalis#509.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The new plugin exposes some layer control functions over Focus, to be able to
control layers from the host side.
Fixes#780.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When setting the idle timeout to zero, stop checking for idleness, and never
turn the LEDs off. Setting the timeout to a higher value again will resume the
plugin's functionality.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When handling the `led.brightness` command, we forgot to break out of the switch
statement, thus executing the `setall` branch too. This resulted in very slow
operations, because we had to wait for a read to timeout.
Adding a break fixes all that.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This changes the IdleLEDs plugin to only re-enable LEDs if they were disabled
due to idleness. If they were turned off any other way, the plugin will not
re-enable them. This makes it play better with the `Key_LEDToggle` key.
Fixes#790.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The new `.setBrightness()` and `.getBrightness()` methods control the brightness
of the LEDs, by dispatching them to the LED drivers. We dispatch to the drivers
so that nothing else needs to be aware of brightness control. Plugins will
always set the unadjusted colors, and anything and anyone who reads colors, will
also get the unadjusted values.
Pushing the adjustment down to the driver level makes everything smooth, and
since we do gamma correction there anyway, it makes sense to do brightness
adjustment at the same place, too.
Fixes#775.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This adds `LEDControl.disable()` and `LEDControl.enable()` which disable and
enable LED operations, respectively. These are meant to replace the current
`LEDControl.paused` property (which is getting deprecated with this change), and
do some additional work on top of just disabling or re-enabling future updates
and sync. Namely, `disable()` will also turn LEDs off, while `enable()` will
refresh them all, too.
We also add a dedicated `Key_LEDToggle` key to disable/enable LEDs. This is
useful when one wants to turn LEDs off, without changing active LED mode to
`LEDOff`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The USB-Quirks plugin was relying on the old HIDAdaptor APIs, including
the (undocumented) defines that enable/disable the boot keyboard. Since we no
longer have those defines, the plugin was effectively a no-op.
This updates the plugin to work with the new APIs, without the need for ifdefs.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To make it easier to configure which HID implementation - and which parts of it
- a particular board uses, we turn our current HID facade (`kaleidoscope::hid`)
into a proper, Props-supported driver. This also allows us to get rid of the
`Kaleidoscope-HIDAdaptor-KeyboardioHID` library.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
- Rewrite decay code to fade brightness smoothly with an x^4
relationship
- Fade hue linearly from orange to red rather than for a subset of
time from red to orange
Signed-off-by: Bart Nagel <bart@tremby.net>
This was done to enable separate inclusion of the central runtime
class without having to include the central header
kaleidoscope/Kaleidoscope.h which used to pull in a lot of stuff that is
not required in many compilation units.
The new class `Runtime_` lives in namespace kaleidoscope its singleton
instance is `kaleidoscope::Runtime`. It is now only available internally
in library Kaleidoscope but not from the sketch.
The original class name `Kaleidoscope_` in global scope has been deprecated.
The original instance name `Kaleidoscope` in global scope has been
preserved to be used by end users in their sketches.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
This implements an extension to the `TapDance` plugin, allowing us to store
`tapDanceActionKeys()`-esque lists in Storage. The core idea here is very
similar to that of `DynamicMacros`: we dump/restore the full list via Focus,
build a cached index on setup and any updates, and play back the selected key
when need be.
Unlike `DynamicMacros`,this plugin is built on top of `TapDance` and cannot
function without it.
Fixes#730.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The submember is a bitfield that needs its own braced list.
Gcc silently tolerates this clang warns about it.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
Clang seems to have problem with recognizing that those
functions are actually static members. This change
makes it more obvious to the compiler, which functions we actually refer
to.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
We'd like to be able to run custom code whenever the led mode changes, reliably,
without having to resort to checking the mode every cycle. For this purpose, we
introduce the `onLEDModeChange()` handler plugins can hook into. It will be
called every time `LEDControl.set_mode()` is called, even if that just sets the
mode to the currently active one.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Using call by reference in FocusSerial::send(...) and
FocusSerial::sendRaw(...) causes linker errors due to
undefined symbols if constexpr constants are passed to the
methods.
This is because if a constexpr value is bound to a reference
this is the same as taking the address of the value. Thus,
the compiler has to generate an instance. Some constants
like e.g. FocusSerial::NEWLINE do not come with an
instance.
This seems not to cause problems with avr-gcc up to now
but generates linker errors during virtual compiles with later gcc
versions (e.g. gcc 8.3.0).
This change does not incur any additional overhead as
all version of FocusSerial's send methods are already inlined,
and the templated versions root to the non-template versions of the send
methods that only accept call-by-value anyway.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
Unions are a C-reminiscense that are better avoided in modern C++.
They cause specific problems due to their nature of representing
independent types. The way they are used in Kaleidoscope, they
can easily be replaced by a class.
This enables it to properly work with Key objects in constexpr context
where with the old union-based implementation the compiler reported
errors when one Key was constructed based on a key_code/flags pair and
another one through raw-data. In such a case, the compiler assumes that
both Key instances represent something entirely different. This is
because unions were never meant for type conversions and the C++
standard considers their use for that purpose as undefined behavior.
The new class provides accessor methods for raw-data access and for
key_code/flags-data access.
This is a breaking change as it is is not possible to replace direct
member access patterns like
key.raw = 0xFFFF;
based on the raw-accessors.
For the .keyCode and .flags members, proxy objects are used
to enable the generation of suitable deprecations warnings.
All direct access via .raw, .keyCode and .flags have been replaced
throughout Kaleidoscope.
Information on how to upgrade is provided in UPGRADING.md
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
We have a few AVR-specific things which do not have a guard yet, and cause
issues on other architectures. This adds those missing guards to the following
places:
- The `kaleidoscope::Hardware` base class, which is deprecated, but still
exists. As such, it needs to be restricted to AVR devices only (since that's all
it supported, non-AVR devices should use the new APIs).
- `device/keyboardio/twi` are only used by the Imago at the moment, and is
AVR-specific, so guard that too.
- Removed an unneeded include from `driver::bootloader::None`, because it
doesn't need `<avr/wdt.h>`.
- `plugin::FirmwareDump` is now restricted to AVR, because that's the only
architecture we support dumping the firmware on.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This implements a new plugin, `PersistentLEDMode`, whose single purpose is to
store the current LED mode to storage, whenever it changes. Since we can't hook
into led mode change events yet, we abuse the `afterEachCycle()` hook to compare
the current led mode to what we think it is, and store it if it changes.
This is obviously not very elegant, but the best we can do right now.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Having to recompile and re-flash firmware to set the idle timeout of the plugin
isn't a fun or desired experience. It's fine when one already figured out the
timeout they want, and have no desire to change it. For everyone else, being
able to configure it at run-time via Focus, and have it persist to EEPROM is a
much nicer experience.
This change adds an alternative version of the plugin, `PersistentIdleLEDs`, a
subclass of the original one. This one provides the focus command and
persistence. It's a child class, because that results in a smaller footprint
than a separate plugin that calls the `IdleLEDs` object.
The code borrows from - but is not wire-compatible with - Dygma's implementation
by @mattvenn.
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>
Deprecate Model01-TestMode, in favour of the newer HardwareTestMode plugin. We
also turn it into a no-op, so that we don't need to update it for API changes
coming in the near future.
The Model01 example has been updated to use the newer HardwareTestMode instead.
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>
When deciding how much data to work with, store the number of LEDs on the board,
not the number of keys. Boards may have less or more LEDs than keys, and since
the plugin is supposed to support theming the LEDs, that number is the one we want.
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>
We want to keep `key_hue` below 255, without clipping it there, otherwise the
effect will come out glitchy. To achieve that, we simply substract 255 until
we're above the cap. This results in the rainbow being laid out in a kind of
wave.
Previously, we didn't do this in a loop, which only worked when the device had
less than 128 LEDs. For devices with more, we need to do this in a loop, until
we get below the cap.
Based on #664 by @mattvenn.
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>
In `refreshAt()`, we want to use the key address, instead of the LED address.
`LEDControl` will turn the key address into a LED address itself anyway. This
not only makes the code a tiny bit more efficient, but it also fixes
`refreshAt()`, which was refreshing the wrong key since the conversion to
`KeyAddr`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In order for the plugin to work without having to switch layers once, it needs
to scan the keymap for modifiers at setup time too. We do this by calling
`onLayerChange()`, which already does that.
Fixes#670.
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>
Virtual builds use their own versions of pgm_read_...
Some of those caused warnings that needed to be silenced by proper casting.
In one place in LEDEffect-BootAnimation, this reveiled an error where a word was
read and then assinged to a byte value. This was fixed as well.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
This caused a problem with virtual builds. The BootKeyboard
header has to be brought in explicitly.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
Instead of having `Key_mouseL` & `Key_mouseUp` override `Key_mouseR` &
`Key_mouseDn`, respectively, stop mouse movement on a given axis when both keys
are held simultaneously. Doing so will not reset acceleration, so when one of
them is released, the mouse will resume movement at full speed immediately.
Closes#634.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Also, instead of using a special timestamp value of zero to indicate that the
keyboard is , use a new boolean variable to indicate that the keyboard is
locked.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Also, change timestamp from four bytes to two, and instead of using a special
timestamp value of zero to indicate that no timer is running, use
`last_tap_dance_key_`.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Also, change `rainbow_update_delay` from two bytes to one, and use a more
consistent interval by adding it to `rainbow_last_update` after each update,
rather than using the current time.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Also, change `update_delay_` from two bytes to one, and use a more consistent
interval by adding it to `last_update_` after each update, rather than using the
current time.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Also, change the update interval value from a preprocessor macro to a static
constexpr uint8_t variable.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Alos, don't bother to set `start_time` in `onSetup()`; it's
unnecessary. Instead, call `findLed()` there.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Also, instead of using `end_time_ == 0` as a special value to indicate that no
timers need to be checked, us `last_key_left_` & `last_key_right_`. This avoids
the bug that could occur when `millis()` returns 0 (which is unlikely, but
possible).
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
In addition, the interval `syncDelay` was changed from a two-byte integer to a
one-byte integer, because LED update intervals longer than 255ms would be
user-visible.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Reading a word and then assigning to a byte does not make sense.
Changed to reading a byte instead.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
After changing the linker command line in platform.txt
in a way that linker error problems are fixed, this
statement is no more needed.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
This commit does the following:
* factor out class AccessTransientLEDMode to an individual file
* factor out class LEDModeInterface to individual files
* fix the file header comment in LEDMode.h
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
The cubic acceleration function used to approximate a sine wave produced some
noticeable jumps when beginning to accelerate the mouse cursor movement (several
1s, followed by several 4s, then 7s, with no intermediate values). This
parabolic function produces smoother mouse cursor motion, without any sudden
jumps in speed.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This PR introduces the concept of dynamic LED modes. Those are LED modes whose class instances
have a restricted lifetime that lasts only as long as a LED mode is active. By this means
it is possible to support a greater amount of LED modes - especially RAM-hungry ones - in the same firmware build. The amount of RAM used to store dynamic LED modes is now bounded
by the maximum size (`sizeof(...)`) of the largest dynamic LED mode.
Old-style LED modes are furtheron called _static_ in the terminology of this PR. They are still supported and blend in nicely with the newly introduced dynamic LED modes.
All changes are entirely backward compatible. No user sketches or existing user plugins require changes.
The greatest benefit of this change is that it drastically reduces the consumption of RAM
when multiple complex LED modes are used. Currently the most complex stock LED mode is
the wavepool effect. Its plugin requires around 140 bytes of RAM that are statically allocated and cannot be shared with any other features.
With this change it becomes possible to have a large number of such resource-hungry LED modes in parallel without a significant gain in RAM consumption.
For the stock firmware this change means a small (~30 byte) growth in terms of PROGMEM. On the other hand it reduces the amount of statically consumed RAM by ~90 bytes. As the current atmel architectures come with around ten times as much PROGMEM as RAM, this means a great improvement as RAM is the more critical resource.
If the wavepool effect, a especially RAM-hungry LED mode is added to the stock firmware,
the saving of RAM increases to 160 bytes which is almost 8% of RAM of the Keyboardio Model01.
A new interface class `LEDModeInterface` was introduced that those plugins
that export dynamic LED modes inherit from. To remain backward compatible, the `LEDMode` class that all pre-existing LED mode plugins inherited from is also derived from `LEDModeInterface`.
The new interface class currently lives in header `LEDMode.h` (see information about this new header below). This is because `LEDMode` and `LEDModeInterface` will
always be used together by dynamic LED modes. Thus, an extra header for `LEDModeInterface` would only mean extra include work for users writing plugins.
Those plugins that export dynamic LED modes must furtheron provide a exported type `DynamicLEDMode`.
This can either be done by defining a nested class of that name or by typedef-ing a class that is defined at global scope to `DynamicLEDMode`. See the modified stock LED modes for examples.
Some of those plugins that export dynamic led modes require access to their particular
dynamic LED mode. By adding the macro `ACCESS_THIS_LED_MODE` to the plugin class definition,
additional data and methods (an integer `led_mode_id_) are synthesized, that enable the plugin class to gain access to their particular dynamic LED mode instance (as long as it is active).
The synthesized integer member `led_mode_id_` can be used to query if the currently active LED mode is the oned handled by the plugin class instance (note that there might be more than one plugin instance of the same class and thus also several dynamic LED modes, see e.g. the solid color LED mode).
A query in the plugin's event handler e.g. looks as follows.
```cpp
if (::LEDControl.get_mode_index() != led_mode_id_)
return EventHandlerResult::OK;
```
All stock LED modes have been adapted to export dynamic LED modes (if possible).
This does not apply to all of them as for some the transition would have provided no gain.
It would even have meant a deterioration of resource consumption for those few pre-existing stock LED mode plugins that hardly have no (static) data-members at all (like e.g. `LEDOff`).
To reduce the amount of compile unit and header interdependencies, the class `LEDMode` has been moved to a header/implementation file of its own.
The `LEDControl` class now does not have a static array anymore to store LED mode pointers.
Instead, it delegates the core LED mode handling to a newly introduced `LEDModeManager` class
that lives in internal namespace. The `LEDModeManager` class is there to restrict access
to LED modes but also to wrap up core LED mode handling. If this functionality would
have been added to class `LEDControl`, far too much of the internals of LED mode handling would have been exposed to users through header `LEDControl.h`.
The new internal header `array_like_storage.h` contains a template class that is used to generate
array-like storages. Here array-like means that the contained pieces of information
are stored contiguously in memory in the same way as they would be when defining
language intrinsic (C-style) arrays. This type of storage is especially useful to generate array-like data struktures
in PROGMEM at compile time based on a list of global objects or POD data. By casting the array-like storage's address
to the content's pointer type, an array-like indexed access is possible.
In this PR an array-like data structure is used to generate a PROGMEM
array of LED mode factories. Array-like data structures could also become useful in other places and for future applications.
The most complex part of the implementation of the new LED mode handling is wrapped up in
`LEDModeManager.h` and `LEDModeManager.cpp` to hide it from users' site.
There, recursive template classes are used to setup an array-like data structure of `LEDModeFactory` instances in PROGMEM. Each of the stored `LEDModeFactory`s are associated with one LED mode-plugin as specified in the sketch. The template mechanism filters out any other plugins unrelated to LED modes. `LEDModeFactory`s thereby handle both static and dynamic LED modes.
Class `LEDModeManager` provides access to the LED mode factories and LED modes in general. It exports methods to query the number of LED modes and to activate a LED mode by its mode-ID. Most of this is only available to `LEDControl` that represents the actual user interface.
When a dynamic LED mode is activated, a dedicated `LEDModeFactory` generates an instance of the dynamic LED mode class in the
LED mode buffer. This buffer is shared by all dynamic LED modes. Its size has been determined at compile time by examining all exported dynamic LED mode types and determining the maximum necessary amount of RAM to store any of those.
All LED mode handling related data structures are generated at compile time, based on
the list of plugins that are passed to `KALEIDOSCOPE_INIT_PLUGINS(...)`. This function macro invokes a new function macro `_INIT_LED_MODE_MANAGER` from `LEDModeManager.h` that handles the LED mode related stuff.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
This is a short-term solution for the problem of qukeys rollover from
mod-flagged keys. When flushing its queue, Qukeys stashes a copy of the
current keyboard HID report, and bases the new (usually mid-cycle) report on
the previous one, because it's complete, unlike the partial current report. This
prevents bugs where it would cause undesired repeats of keys scanned later in
the cycle, but results in a bypassing of the system in the HIDAdaptor that masks
modifier flags when rolling over to a key without those flags.
By first storing a copy of the previous key report's modifiers byte and then
restoring it after the report for a released qukey is sent, we remove any
modifier flags it added to that report, so the next key in the queue (if any)
won't base it's report on those modifiers (which would normally be masked by the
HIDAdaptor).
This is a temporary fix. The real fix will probably involve changes to both
KeyboardioHID and the HIDAdaptor, and will allow Qukeys to stop accessing the
HID reports, which really ought to be private member variables of the Keyboard
class.
Fixes#619.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Previously, if a Topsy key was pressed, then a non-Topsy key was
pressed, then the Topsy key was released, we'd return the event consumed
before toggling off the active state, leaving Shift keys consumed until
a Topsy key got pressed again.
Toggle the active state before the early return for Topsy key events.
Signed-off-by: Lisa Ugray <lisa.ugray@gmail.com>
If we found no modifiers on the current layer, force a re-scan. This way we'll
scan the keymap without having to change layers first. We can't do the same
thing at `onSetup()` time, because that's too early, so we do a check in
`beforeReportingState()`.
Fixes#608.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
OneShot keys were failing to activate on the first press because of how the timeout was
implemented. Most of the time, at the end of a cycle, `should_cancel_` was being set to
`true` because the current time was being compared to the last time a OneShot key was
activated, regardless of whether or not a OneShot key was active. As a result, OneShot
keys that were pressed for the first time in a while would fail to register as OneShots.
This change prevents checking the timeout unless there is an active OneShot key.
Fixes#603.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This should stop layers from getting stuck on when a release delay is in use. Instead of
recording the keycode of the key that will be released, I now have Qukeys just use the
key's coordinates, and have it do a lookup in `Layer.live_composite_keymap_` the usual
way.
I also stopped overloading the `key_queue[x].start_time` and instead record the release
delay time in a separate variable. This greatly simplifies the timeout math, and saves
another good-sized chunk of PROGMEM, as well as avoiding timeout-conflict bugs.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Now, when we flush a key from the queue, we just insert whatever its final `Key` value
should be into `Layer.live_composite_keymap_`, obviating the need to independently track
whether a flushed qukey is in its primary or alternate state. We can also get rid of all
the code for correcting `mapped_key`, because once a key has been flushed, it won't show
up as a qukey (or DualUse key) any longer.
This substantially reduces PROGMEM usage (~300 bytes) and reduces RAM usage by 8
bytes (for the Model01 hardware).
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
With qukey defined with an alternate `Key` value of `ShiftToLayer(N)`, we need a way to
send the toggle-off event in order to get the layer to deactivate. Since the physical key
was already released, we need to keep track of the delayed-release qukey, and send the
appropriate release event after the rest of the queue has been flushed.
This change records the delayed key at the time of the delay, and sends the release event
after the ensuing key has been flushed from the queue.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
With the changes to the updating of `Layer.live_composite_keymap_`, the code that changes
the `mapped_key` values for keys that have been flushed from the queue is unnecessary.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
SpaceCadet was sending a keyswitch event with the row & column coordinates of the wrong
key. The coordinates were coming from the keypress, but the injected event was for a
previously-pressed (different) key that's still held. With the mutable
`live_composite_keymap_[]` change, this meant that pressing (and holding) `shift` then
another key would result in only a single character, rather than a repeating
character. Regardless of the minor bug, using the row & col for the event was still
logically incorrect here.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
If we're sending injected events with `UNKNOWN_KEYSWITCH_LOCATION` instead of
the (row,col) of the OneShot key, there's no need for the function that does this
conversion.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
With the changes to live_composite_keymap_, OneShot keys were no longer working. OneShot
modifiers would get stuck on, because the entry for the `OSM` key would get changed to the
modifier key value, and when the key was released, it wouldn't be processed by the OneShot
plugin, which would continue to re-apply the modifier indefinitely. At the same time,
OneShot layers wouldn't work at all, because the key would get changed to the layer shift
key, which would then turn the layer off when it was released.
This change fixes the problem by injecting keyswitch events from OneShot without physical
key coordinates, so nothing in `live_composite_keymap_` can get updated from it. OneShot
wants the `Key` entries there to remain as OneShot keys, not as whatever they're changed
to, so this is the most appropriate way I can think of to fix the issue.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Instead of trying to be clever by checking if a mask applies to a layer index,
just check if the layer is higher or equal (or lower, as appropriate) than our
`IGNORE_HARDCODED_LAYER` value.
This addresses keyboardio/Chrysalis#341.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Since LED modes only send updates to the hardware at `syncDelay` intervals, calling
`update()` on the active mode every cycle doesn't make animations any smoother.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This decreases the rate at which LEDs get updated from ~60Hz to ~30Hz, which should be
fast enough that human eyes won't be able to tell the difference.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The LED-Stalker plugin was looping through its table of `step` values (one for each key)
on every call to `update()`, and calling `compute()` on every value there, but those table
entries were only updated once every 50ms (by default), resulting in a lot of repeated
computation. This resulted in the mean idle cycle time increasing from 565µs to 1317µs on
the Model01 with an (almost) unmodified standard sketch.
This change moves the check for the timeout before the loop through the `step` values, and
aborts processing there if not enough time has elapsed. The resulting mean idle cycle time
becomes 577µs -- an almost negligible increase. It also reduces the PROGMEM footprint by
44 bytes.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
On AVR8, 16-bit bit-operations are expensive. Switch from using 3 16-bit
bitfields to using a 16-element array of a carefully constructed struct.
This saves us almost 300 bytes of PROGMEM at the cost of 10 bytes of memory.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
I tried to be smart and use `sizeof()` instead of hard-coding the array size,
but I used it wrong, and we iterated to 32 instead of 16, overflowing the array
and looking at parts of the memory we had no business looking at. This resulted
in `isPressed()` and `isSticky()` always being true.
Instead of trying to be clever, use `OneShot::ONESHOT_KEY_COUNT` throughout,
which is a constexpr defined at 16, the number of oneshot keys we have.
Fixes#572.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In `beforeReportingState()` and `afterEachCycle()` we used to return early if no
OneShots were active. This was easy to do when we were using a bitfield, we'd
just tested for non-zero. Since we're using an array now, this check is more
expensive, and the extra work negates any benefit of returning early.
For this reason, these early returns are removed.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Now that we're using a struct with descriptive member names, drop the helper
macros that made using bitfield manipulation readable. The code's readable
without them by now.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
On AVR8, 16-bit bit-operations are expensive. Switch from using 4(!) 16-bit
bitfields to using a 16-element array of a carefully constructed struct.
This saves us about 242 PROGMEM at the cost of 8 bytes of memory, and a tiny
performance hit.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
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>
Previously we requested a slice in `onSetup()`, but this had a major,
problematic implication: if we went from a sketch with `EEPROM-Keymap`, but
withot `LED-Palette-Theme` enabled to one with it, the EEPROM layout was not
compatible, no matter what the order of plugins in `KALEIDOSCOPE_INIT_PLUGINS`
were. This happened because `EEPROM-Keymap` requested space *after* `onSetup()`
already ran.
To fix this issue, request a slice in `.reserveThemes`, only if we didn't
request a slice yet. This way the EEPROM layout is decided by the order of
initialization in `setup()`, and we do not sneakily steal a slice in
`onSetup()`.
This is required to address keyboardio/Chrysalis#270.
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>
Counting cycles is an incredibly unreliable way of timing animations. Use timers
instead.
Fixes#545.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When not using the `CRGB()` macro, colors may end up being different than
intended if the board we're running on implements RGB order differently.
Fixes#548.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Since `Focus.send()` does not send a newline implicitly, we should do so
explicitly. Introduce `Focus.NEWLINE` to help with this, and not have many
copies of `'\n'` lying around.
Fixes#544.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We deprecated a number of interfaces, which were scheduled to be removed on the
14th of January. Lets remove them now.
Incidentally, we had a number of places where we used the old names internally
too, and this has been corrected as well now.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
EEPROM defaults to `0xff` when uninitialized, which means we'd start off with a
bright white palette. That's a problem, because it draws a lot of power,
especially when all keys are lit bright. For this reason, flip the bits when
reading or storing palette colors, so the default `0xff` becomes `0x00`, black.
Fixes#529.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Brace-initialization has issues, especially with newer compilers that try to do
more, and better optimizations. To allow them to do these, we should be striving
for better type safety. For this reason, use the new Key() constructors to
initialize the various key defines. This gives the compiler much better hints.
The code becomes much more readable too.
This is fully backwards compatible, we're not removing any existing interface,
just using a newly introduced one. The old ways still work. They might produce
warnings with newer compilers, but they did so before anyway.
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>
Gergely Nagy
Jesse Vincent
Gergely Nagy
Bart Nagel
Florian Fleissner
Michael Richters
tiltowait
ash lea
Florian Fleissner
Jesse Vincent
Lisa Ugray
Jordan Galby
Scott Perry