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>
Gergely Nagy
Jesse Vincent
Jesse Vincent