keyboardio / kaleidoscope-ledcontrol

LED Control plugin for Kaleidoscope.

Kaleidoscope-LEDControl

This is a plugin for Kaleidoscope, for controlling the LEDs, and LED effects.

kaleidoscope-ledcontrol's Issues

LED mode stacking

Based on keyboardio/Kaleidoscope-LEDEffect-SolidColor#2, #9, and LED mode interaction issues between ActiveModColor and others, I have a proposal: instead of having LED modes that have near-exclusive control over the LEDs, and a few special plugins like ActiveModColor that try to play well with them (but sometimes fail at that), how about making it possible to have more than one LED mode active at any given time? Similar in spirit to how layers work.

This way, ActiveModColor and NumLock would have it easier, as they'd just set the LEDs they want, and leave the rest to the modes that came before them. You could even have RainbowWave, Stalker, Wavepool, and ActiveModColor all active at the same time!

For this to work, we need to have an array that lists the modes we want (we already have this), a bitmap that describes which ones are active (we can use an uint16_t for this), and change a few methods to iterate over the active ones instead of calling the appropriate function for just one.

At a next step, we can optimize the LED modes further so that we iterate over the whole keymap only once instead of potentially as many times as we have active modes...

With this setup, we could rename LEDMode methods to:

• setup(void) (or begin, depending on how we implement it): Called once when Kaleidoscope.use()-ing the plugin.
• activate(void): Called whenever the mode is activated.
• update(void) (or update(row, col)): The brains of it, called every cycle to update the LEDs.
• deactivate(void): Called whenever the mode is deactivated.

Brightness jump from timer overflow in breath_compute

Every 65 seconds, the 16-bit value from millis() overflows, and there's a sudden jump in the brightness for Kaleidoscope-LEDEffect-Breathe.

Support for Underglow (along with per-key LEDs): LED grouping?

@Dygmalab's Raise will be using Kaleidoscope for its firmware, they have both per-key LEDs and some 30-odd LEDs around the frame for underglow. It would be incredibly awesome if we could easily support both. Being able to address the underglow LEDs is just one thing. We also need a way for LED effects to make use of them, since most are using the ROWS / COLS constants, and as such, are limited to per-key LEDs.

I have a couple of ideas which I'll explain below, but those are just that - ideas. The goal is to support both underglow and the existing per-key LEDs, in a convenient, and backwards-compatible manner.

Clean up methods in LEDMode class

Currently LEDMode has three separate methods called begin(), setup(), and init(), and it's not clear what the distinction is between them, or how new LED modes should choose which one (or more) of them to override.

Focus: Add a way to get/set the LED color map

It would be really useful if we could update the active LED theme, without having to set each LED one by one, but by uploading a theme in one command.

Calling led_sync every cycle kills performance

As the title says, see keyboardio/Kaleidoscope#113 for the discussion. Short version is that adding the LEDOff effect to a sketch that has a main loop run at 2.2-2.4ms, pushes the duration towards 10ms, usually over it, too.

Perhaps it would be enough to call led_sync fewer times. If I'm not mistaken, calling it every ~16ms would still result in ~60 updates / second (which is plenty), and have a much smaller impact on average loop length.