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>
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>
Rearranged the columns so we can do some bit shifting and OR-ing magic instead
of manually picking bits from various pins.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In the Topsy case, pre-calculate `mapped_key.raw` for both branches, and only
modify its flags in the unishfted branch. This saves us about a dozen bytes of
PROGMEM.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We do not need to track which shift is pressed, so lets use a bool instead of a
bitfield. Makes the shift checking code smaller too!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Like in the unshifted case, avoid injecting keys, and fiddle with `mapped_key`
instead. This allows us to get rid of the `TOPSYTURVY` bitflag.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is to avoid the case where chording a Topsy and a non-Topsy key would
result in both being repeated very fast. This happened because each cycle we
sent two reports: one for the Topsy key, one for the others. This didn't allow
the host's normal repeating behaviour to kick in, and instead, resulted in both
keys being input very fast.
Fixes#5.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We're not calling `onKeyswitchEvent` in the idle cases anymore, drop the check
for a few bytes saved.
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>
TopsyTurvy derived from `KaleidoscopePlugin`, which was part of the V1 plugin
API, and has been recently removed. Use `kaleidoscope::Plugin` instead, which is
its replacement.
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>
ShapeShifter derived from `KaleidoscopePlugin`, which was part of the V1 plugin
API, and has been recently removed. Use `kaleidoscope::Plugin` instead, which is
its replacement.
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>
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>
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>
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@madhouse-project.org>
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 a key was released, we were failing to send the release event explicitly. For most
plugins, this didn't matter, but it was causing a problem for Leader, which acts on
release events. By returning `EVENT_CONSUMED` instead of `OK`, we were stopping the
release event from getting through to Leader, and thus a qukey with a Leader key as its
primary keycode would fail.
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>
If we do not clear `should_cancel_` there, it remains set indefinitely (until it
gets unset for some other reason, like interrupting a non-sticky OneShot). If it
is set, we can't enter sticky mode.
So clear it when canceling stickiness with a third tap, just like we clear it in
`afterEachCycle`.
Fixes#34.
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>
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>
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>
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>
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>
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>
Unfortunately, the way we reported the use of an old-style API also triggered
when not using it. Change that to only trigger when we DO use the old API, by
marking the `combo_t` constructor private.
Unfortunately, this does not allow us to use a custom error message.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of manually counting set bits, use gcc's `__builtin_popcount()` for a -
supposedly - more efficient count.
Also initialize the counter to zero, while there.
Fixes#11.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of iterating through all the bits, use `__builtin_popcountl()`, provided
by gcc, which should be considerably more efficient.
Fixes#27.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
`Consumer_SNapshot` really should have been `Consumer_Snapshot`, so lets fix it.
However, the typo'd name is left in place as an alias, in order to not break any
existing user code, however unlikely the use of this key is.
Sadly, we can't easily add a deprecation warning, because key_defs.h, which
defines `Key`, depends on `key_defs_consumerctl.h`, so we'd end up with a
circular dependency if we tried to add a deprecation.
Fixes#339.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
As per UPGRADE.md, remove `Kaleidoscope.setup(KEYMAP_SIZE)`,
`event_handler_hook_use`, `loop_hook_use`, `USE_PLUGINS`, `MOMENTARY_OFFSET`,
`key_was_pressed`, `key_is_pressed`, `key_toggled_on`, and `key_toggled_off`.
These were deprecated between July and October 2017, and have been marked for
deletion for over a month.
Also updated UPGRADE.md, moving the section about these to a new, "deprecated
and removed" section.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When using the old API, fail with a helpful error message that points to
`UPGRADING.md`, which explains in simple detail the migration process.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The old `RxCy` macros were recently changed to be key indexes instead of
per-hand bit indexes, and `KeyboardHardware.isKeyswitchPressed()` and
`KeyboardHardware.pressedKeyswitchCount()` were introduced as a way to peek into
the keyswitch state. This little change migrates TestMode to use them.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using a list of left/right-hand states and an overrideable global
callback, use a map of action and key-list pairs. This makes the plugin much
more portable, does not require any hardware-specific knowledge within the
plugin, and does not require us to treat the hands separately.
This in turn, results in a friendlier user interface, at the cost of limiting
the maximum length of a combination to five keys. A small price to pay.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of `getKeyswitchStateAtPosition`, which is long, unintuitive and feels
wrong too, introduce `isKeyswitchPressed`, shorter, better, more
reasonable (because it returns a bool - we support only two states anyway!).
Additionally, add `pressedKeyswitchCount()`, which returns the number of key
switches pressed.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of `getKeyswitchStateAtPosition`, which is long, unintuitive and feels
wrong too, introduce `isKeyswitchPressed`, shorter, better, more
reasonable (because it returns a bool - we support only two states anyway!).
Additionally, add `pressedKeyswitchCount()`, which returns the number of key
switches pressed.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is sufficiently low-level that it is OK to use `KeyboardHardware` for it.
It's not a HID thing, either.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Move `KEY_INDEX` here, and turn it into a `constexpr` function, `keyIndex`, and
convert the `RxCy` macros to constexpr values instead.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To allow the hardware plugin to use a more efficient way of representing the
index (if need be), and to be able to turn it into a constexpr, move it to the
hardware plugin.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To be used by the hardware implementations, `KEY_INDEX` tells us the index of a
key, from which we can figure out the row and column as needed. The index starts
at one, so that plugins that work with a list of key indexes can use zero as a
sentinel. This is important, because when we initialize arrays with fewer
elements than the declared array size, the remaining elements will be zero. We
can use this to avoid having to explicitly add a sentinel in user-facing code.
Additionally, we add `getKeyswitchStateAtPosition` to the HID facade. See its
documentation in `Kaleidoscope-Hardware`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Implement `getKeyswitchStateAtPosition`, a hardware-agnostic way to peek into
the keyswitch state. Also transition the `RxCy` macros to `KEY_INDEX`, to make
it easier for hardware with more keys than 64 to implement them, and to make
their values unique across a keyboard, not just across a keyboard half.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of only having an ifdef in the body of deprecated methods, and leaving
it up to the compiler to optimize out the empty & unused, explicitly wrap the
declaration of them within an ifdef too. This will make it easier to remove
everything V1 at a later point, and we're not at the mercy of the compiler,
either.
Fixes#327.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We do not want user code having to deal with KeyboardHardware, so wrap
.detachFromHost and .attachToHost ourselves.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
These functions can be used to detach from the host, then re-attach, possibly
with different properties, without having to reboot the device.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Having it at the brightest uses too much power, and may result in power use
surges when switching between LED modes and NumPad, which in turn can force the
operating system to disable the whole device. To avoid this, lower the
brightness to 160, a carefull tuned value, also used by the `solidRed` mode in
the factory firmware.
Fixes#9.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The multiplication by 99 can overflow an int8_t depending on whether the
expression is coerced to a regular-sized int (based on the 99 literal).
Just to be safe, perform a cast to int16_t in case the coercion does not
happen.
Previously, diagonal movements were not reduced in the two axes,
resulting in movement that was too quick. This commit divides diagonal
movements by sqrt(2) / 2 to correct the movement speed.
The net result is that diagonal movement should feel smoother and speed
more as expected.
This removes WakeupKeyboard, because a similar feature was integrated into
BootKeyboard itself, rendering it useless.
See keyboardio/KeyboardioHID#35 for an explanation of the whole situation.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of repeating the same cRGB reading code in three places, use the
recently introduced Focus.readColor() function. This both makes the code
cleaner, and more than 50 bytes smaller too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using a lambda (which is not constexpr in C++11), use a temporary,
anonymous struct instance to wrap the `static_assert`, which is constexpr in
C++11.
Fixeskeyboardio/Model01-Firmware#53. Thanks to @noseglasses for finding the
cause, and explaining the fix!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Many plugins use timers, and most of them will call `millis()`, which isn't
wrong, but isn't the most efficient either. While `millis()` isn't terribly
expensive, it's not cheap either. For most cases, we do not need an exact timer,
and one updated once per cycle is enough - which is what `.millisAtCycleStart()`
is. Having a timer that is consistent throughout the whole cycle may also be
beneficial.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Jesse Vincent
Jesse Vincent
Gergely Nagy
Csilla Nagyné Martinák
Gergely Nagy
matt venn
Ben Gardiner
Gergely Nagy
Shriramana Sharma
Michael Richters
Daniele Tamino
Jack Zhou
Aaron Christianson