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>
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 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>
For a while now, Kaleidoscope does nothing if keys are idle. This example relied
on events being fired in the idle case too. So instead of relying on that, move
the holding logic to `loop()`.
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>
Jesse Vincent
Michael Richters
Shriramana Sharma
Daniele Tamino
Gergely Nagy
Gergely Nagy
Alessio Di Mauro
matt venn
James Cash