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>
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>
To make it easier to use the plugin, pull in `EEPROMSettings` by default, and
explicitly call its `onSetup` (it is safe to do so), so user sketches don't have
to if they don't use `EEPROMSettings` directly. Also set `Layer.getKey` to
`EEPROMKeymap.getKeyOverride` to provide a sensible default.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If `EEPROMSettings.seal()` wasn't explicitly called, seal the layout in
`beforeEachCycle()`. On the flip side, this makes user sketches simpler, because
they don't have to seal explicitly. This is done at the cost of an if check each
cycle.
In the long run, EEPROM layout management will be moving out of this plugin, so
this check will be eventually dropped too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
These two lines went in by mistake earlier, they were meant for local
debugging only. As such, having them in the plugin is a bug, easily
squashed by removing them.
Signed-off-by: Csilla Nagyné Martinák <csilla@csillger.hu>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the original plugin was written independently, significant developments
were made while working for Keyboard.io. As such, I feel it is appropriate to
assign copyright to the company.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
After talking with Jesse, this changes the license to GPLv3 (only), where
appropriate, and adds copyright headers to all files that were missing them.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Scheduled for removal on 2018-08-20, this drops the V1 API and all deprecation
messages. We only keep one message, that errors out in case
`KALEIDOSCOPE_ENABLE_V1_PLUGIN_API` is set. Also drops `Consumer_SNapshot`,
which was a typo'd name.
`UPGRADING.md` updated accordingly.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is just to clarify to anyone who may be reading the sources as to why B00100000 is missing from the flags defs. Not a big deal but I thought it would be useful…
This, along with the change
keyboardio/Kaleidoscope-HIDAdaptor-KeyboardioHID@a4368f13e7a1b58e, makes
it so a rollover from a key with a mod flag applied to one without will
not result in the flag from the modified key affecting the next keypress.
The breathe function is somewhat costly and is found to cause drag in
mouse movements. This commit seeks to fix this problem.
It is observed that the function doesn't change output value for every
input value. It only causes the output brightness to increase by 128
units (from 80 to 208) over 2048 ms (the half-period). This means 1 unit
for 16 ms. But a brightness change of 1 unit doesn't mean much visually
especially considering persistence of vision. A refresh rate of 20 per
second ie 50 ms between LED updates is found to be sufficient to avoid
the drag effect while maintaining smoothness in brightness changes.
While we do clear the report every cycle, similar to how key release events are
explicitly removed from the report, mouse movements should get removed too. This
makes it possible to use them in macros reliably, without surprising results (an
extra report sent at the end of the macro).
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This mirrors `moveMouse()`, and the intent is to use it when releasing a mouse
key outside of the main event loop (such as during a macro).
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When using `Kaleidoscope.use()` and the V1 API is disabled, we want to display
an error. The current method of doing that is not reliable, it sometimes works,
sometimes will error out even when not using `Kaleidoscope.use()`. To fix this,
delay the initialisation of `.use()`, so it only evaluates when used, and thus,
only fails with a descriptive error in that case.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Override the copy constructor of `combo_t`, so that we can display an error when
initializing using the old-style API.
Fixes#8.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In preparation for the sunset of the V1 API, when using the V2 API only, give a
nice error message on `Kaleidoscope.use()`, instead of simply not defining it.
This makes the upgrade path a little easier.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When the V1 plugin API is enabled, we need to override `onSetup`, to not call
`setup()` twice: once via the v2 default `onSetup`, and once via the legacy API.
Take special attention to call `LEDControl.mode_add`, so that the effect does
register as a LED mode.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When using the V1 compatibility layer, in the `onSetup()` method, we need to
call `LEDControl.mode_add()`, otherwise the mode does not register, and will not
function.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The default `onSetup` will call `.begin`, to support initializing plugins using
the V1 plugins while using `KALEIDOSCOPE_INIT_PLUGINS`. However, plugins that
implement a compatibility layer so that they can be used with both the new API,
and with `Kaleidoscope.use()` will have a `.begin` method too. Which the default
`onSetup` will call, and we'll register the compatibility layer too, in addition
to the new-style event handlers. This results in many things running twice,
which leads to all kinds of problems.
For this reason, override `onSetup`, so that it does not call `begin`. When used
with `Kaleidoscope.use()`, the plugin will still work, so compatibility is
maintained. But the bug is now gone.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Gergely Nagy
Jesse Vincent
Jesse Vincent
Csilla Nagyné Martinák
Gergely Nagy
matt venn
Gergely Nagy
Shriramana Sharma
Michael Richters
Daniele Tamino