When we light up a new key, clear the previous one (but only if it isn't the
same, to avoid flickering).
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The new singleton objects implements a LED mode where each pressed key
will light up the appropriate symbol on the LEDs, on the side it was
pressed on. We use different timers for each half.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
While it is possible to play with the ->color property, sometimes one
just wants to override the color once. In this case, saving the previous
value, and changing it back would be an overkill.
Instead, add a few functions that take a color argument as well, and
make the color-less arities use the global property.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of using the supplied linear color component values as-is,
convert them to gamma-corrected, non-linear values first. This way, we
can use numbers like 127 to mean half brightness, and have it
automatically translated to the correct, gamma-corrected value.
Table copied from:
https://learn.adafruit.com/led-tricks-gamma-correction/the-quick-fix
This adds a bit over 256 bytes of code, but makes working with colors a
lot easier.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Call `macroAction` for all `keyState`s, not only when a key toggled on. This
lets the macro itself decide when to act, and makes it possible to have macro
effects on the other states.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
We want to allow plugins to change how keys are looked up - or where they are
looked up from -, and for this, the way we do that final lookup from `keymaps`
or elsewhere, must be overrideable.
We do this by having a `getKey` function pointer in the `Layer_` class, which
defaults to `getKeyFromPROGMEM`. Any plugin, or sketch, can change where
`getKey` points to, and thereby change the way keys are looked up.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
If we want to allow plugins to implement EEPROM storage, it is best if we don't
do anything with EEPROM in the core firmware. As such, remove the
`Layer.defaultLayer` call from `Kaleidoscope.setup`.
With that gone, the `keymap_count` argument is obsolete, so drop it from
`Kaleidoscope.setup()` - but we keep an temporary `setup()` with the old arity,
so that plugins can be updated at a slower pace.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Drop the `load_primary_layer` and `save_primary_layer` methods, because
`save_primary_layer` is not used anywhere, and as such, the whole thing is
pointless at this time.
Furthermore, if we want to allow plugins to implement EEPROM storage, then its
best if we leave the default layer save/load to the plugins too.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To further improve the LED performance, sync only when there is a change. We do
this by tracking when change happens, assuming everyone uses the provided
accessors.
While we do a bit of extra work each cycle to do the tracking, that pales in
comparison to what we gain by not having to transfer data needlessly.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Gergely Nagy
Jesse Vincent
Jesse Vincent