The keymap.transfer command is only useful if we have both PROGMEM & EEPROM
keymaps, which will rarely be a case, and likely only temporarily, too. As such,
lift that out of the `focusKeymap` function, into its own. This makes the
command optional, and can save us some 140 bytes of program space (even more if
documentation is enabled).
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Since we always read input sequentially, use a single while loop for both
palette and map input. Less calculations, less code, more free space. And we can
now upload a partial palette too!
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This adds the Kaleidoscope::AlphaSquareSymbols namespace, for symbols that fall
outside of the normal alphanumerics. The first such symbol is `λ`.
Fixes#3.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of having a getter and a setter command, have one with an
optional argument instead. Less code, less docs, easier to use and
understand.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
For similar reasons an the OneShot restriction, cut down the allowed
number of tap-dance keys to 16 (down from 32).
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of having 24 one-shot layers, allow only 8. This allows us to
fit into 16 bits, and will save a lot of program space.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To make it easier in the future to increase the amount of one-shot
layers available, use a union+struct combo, that allows scaling between
16 and 32 bits. This way we won't have to use all 32 bits, and can make
do with 24 only, still saving us almost a hundred bytes.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of supporting up to 24 one-shot layers, support only 8. This
allows us to fit all state in 16 bits, down from 32, saving us almost
200 bytes of program memory.
Partially addresses #8.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
We expect the keymap in EEPROM to be set up by the time we get to use it,
instead of having uninitialized EEPROM there. So remove the special handling of
0xffff.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Allows other plugins to request a slice of EEPROM, and returns the starting
location of their area. Makes a CRC out of the slice sizes, so that it can
detect when the EEPROM and the Sketch become out of sync. Handling that case is
left up to the user.
As a consequence, we no longer reserve a big chunk of EEPROM for the keymap,
that just becomes another slice of it, which can be anywhere. This makes it a
bit harder to adjust the size of it, but as far as this plugin goes, playing
with the EEPROM layout will usually mean having to update its contents from
scratch, anyway.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The `keymap.dump` command should dump up to `maxLayers` amount of layers,
instead of a hardcoded four.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of calling the `.write` method of `ConsumerControl`/`SystemControl`,
which registers the key, sends a report, then unregisters, and reports again,
just `.press` it when the key is pressed, as we did before.
However, since `.press` always sends a report, and so does `.releaseAll`, we
can't have it the same way we do for `Keyboard`. We need to explicitly release
the consumer/system key, when the triggering key is released too. Not doing so
makes the key stuck, as we never release it, and that will upset the operating
system very much.
With this patch, we do an explicit release when the key toggles off, and thus,
we support both holding the key, and allowing the OS to trigger repeat, and, the
key won't be stuck, either!
Fixes#120.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
With these changes, the vertical scrolling of the mouse wheel is now properly
supported. It has no acceleration, because the wheel doesn't have one either. It
has a delay, however, which I tried to tune to a reasonable speed.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
WARP + Button makes no sense together, so reuse the _BUTTON bit for _WARP_END.
This will allow us to use the free'd up bit for something else.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
While it was a neat optimization to only turn LEDs off at init time, that is not
enough if there are other plugins in play, that work with the LEDs independently
of the active LED mode. Such a plugin is LED-ActiveModColor, which never turns
LEDs off, and relies on the LED mode to do that.
Since LEDOff did not turn things off on update(), when used together with
LED-ActiveModColor, the LEDs under the modifiers stayed active, even after the
modifiers went inactive.
With this simple change, LEDOff will now update, and the problem's gone.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
There are - or will be - better ways to experiment, drop these, lest
anyone starts depending on them.
Fixes#7.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When using AlphaSquareEffect, in the event handler hook, return early if the
currently active LED mode is not us.
Fixes#2.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
If we start with isLEDChanged unset, then after flashing, the `R0C0` key will
remain lit, because we think it is off, while it is not. Setting this flag
results in the first update cycle updating everything, no matter what, which is
the safest thing we can do.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Gergely Nagy
Jesse Vincent
Gergely Nagy