|
|
|
#include "Kaleidoscope-LEDControl.h"
|
|
|
|
#include "Kaleidoscope-Focus.h"
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
namespace kaleidoscope {
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
LEDMode *LEDControl::modes[LED_MAX_MODES];
|
|
|
|
uint8_t LEDControl::mode;
|
|
|
|
uint16_t LEDControl::syncDelay = 16;
|
|
|
|
uint32_t LEDControl::syncTimer;
|
|
|
|
bool LEDControl::paused = false;
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
|
|
|
|
void LEDMode::activate(void) {
|
|
|
|
::LEDControl.activate(this);
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
void LEDMode::begin(void) {
|
|
|
|
Kaleidoscope.use(&::LEDControl);
|
|
|
|
::LEDControl.mode_add(this);
|
|
|
|
setup();
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
LEDControl::LEDControl(void) {
|
|
|
|
mode = 0;
|
|
|
|
memset(modes, 0, LED_MAX_MODES * sizeof(modes[0]));
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
void LEDControl::next_mode(void) {
|
|
|
|
mode++;
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
if (mode >= LED_MAX_MODES || !modes[mode]) {
|
|
|
|
return set_mode(0);
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
return set_mode(mode);
|
|
|
|
}
|
|
|
|
|
|
|
|
void LEDControl::prev_mode(void) {
|
|
|
|
mode--;
|
|
|
|
|
|
|
|
if (mode >= LED_MAX_MODES || !modes[mode]) {
|
|
|
|
return set_mode(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
return set_mode(mode);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
LEDControl::set_mode(uint8_t mode_) {
|
|
|
|
if (mode_ >= LED_MAX_MODES)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mode = mode_;
|
|
|
|
refreshAll();
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
uint8_t LEDControl::get_mode_index(void) {
|
|
|
|
return mode;
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
LEDMode *LEDControl::get_mode(void) {
|
|
|
|
return modes[mode];
|
|
|
|
}
|
|
|
|
|
|
|
|
void LEDControl::activate(LEDMode *mode) {
|
|
|
|
for (uint8_t i = 0; i < LED_MAX_MODES; i++) {
|
|
|
|
if (modes[i] == mode)
|
|
|
|
return set_mode(i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
int8_t LEDControl::mode_add(LEDMode *mode) {
|
|
|
|
for (int i = 0; i < LED_MAX_MODES; i++) {
|
|
|
|
if (modes[i])
|
|
|
|
continue;
|
|
|
|
|
|
|
|
modes[i] = mode;
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
void LEDControl::set_all_leds_to(uint8_t r, uint8_t g, uint8_t b) {
|
|
|
|
cRGB color;
|
|
|
|
color.r = r;
|
|
|
|
color.g = g;
|
|
|
|
color.b = b;
|
|
|
|
set_all_leds_to(color);
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
void LEDControl::set_all_leds_to(cRGB color) {
|
|
|
|
for (uint8_t i = 0; i < LED_COUNT; i++) {
|
|
|
|
setCrgbAt(i, color);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
void LEDControl::setCrgbAt(uint8_t i, cRGB crgb) {
|
|
|
|
KeyboardHardware.setCrgbAt(i, crgb);
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
void LEDControl::setCrgbAt(byte row, byte col, cRGB color) {
|
|
|
|
KeyboardHardware.setCrgbAt(row, col, color);
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
cRGB LEDControl::getCrgbAt(uint8_t i) {
|
|
|
|
return KeyboardHardware.getCrgbAt(i);
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
void LEDControl::syncLeds(void) {
|
|
|
|
KeyboardHardware.syncLeds();
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
void LEDControl::begin(void) {
|
|
|
|
set_all_leds_to({0, 0, 0});
|
|
|
|
|
|
|
|
for (uint8_t i = 0; i < LED_MAX_MODES; i++) {
|
|
|
|
if (modes[i])
|
|
|
|
(modes[i]->setup)();
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
Kaleidoscope.useEventHandlerHook(eventHandler);
|
|
|
|
Kaleidoscope.useLoopHook(loopHook);
|
|
|
|
|
|
|
|
syncTimer = millis() + syncDelay;
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
Key LEDControl::eventHandler(Key mappedKey, byte row, byte col, uint8_t keyState) {
|
|
|
|
if (mappedKey.flags != (SYNTHETIC | IS_INTERNAL | LED_TOGGLE))
|
|
|
|
return mappedKey;
|
|
|
|
|
|
|
|
if (keyToggledOn(keyState))
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
next_mode();
|
|
|
|
|
|
|
|
return Key_NoKey;
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
void LEDControl::loopHook(bool postClear) {
|
|
|
|
if (postClear || paused)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (millis() > syncTimer) {
|
|
|
|
syncLeds();
|
|
|
|
syncTimer = millis() + syncDelay;
|
|
|
|
}
|
|
|
|
update();
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
bool LEDControl::focusHook(const char *command) {
|
|
|
|
enum {
|
|
|
|
SETALL,
|
|
|
|
MODE,
|
|
|
|
AT,
|
|
|
|
THEME,
|
|
|
|
} subCommand;
|
|
|
|
|
|
|
|
if (strncmp_P(command, PSTR("led."), 4) != 0)
|
|
|
|
return false;
|
|
|
|
if (strcmp_P(command + 4, PSTR("at")) == 0)
|
|
|
|
subCommand = AT;
|
|
|
|
else if (strcmp_P(command + 4, PSTR("setAll")) == 0)
|
|
|
|
subCommand = SETALL;
|
|
|
|
else if (strcmp_P(command + 4, PSTR("mode")) == 0)
|
|
|
|
subCommand = MODE;
|
|
|
|
else if (strcmp_P(command + 4, PSTR("theme")) == 0)
|
|
|
|
subCommand = THEME;
|
|
|
|
else
|
|
|
|
return false;
|
|
|
|
|
|
|
|
switch (subCommand) {
|
|
|
|
case AT: {
|
|
|
|
uint8_t idx = Serial.parseInt();
|
|
|
|
|
|
|
|
if (Serial.peek() == '\n') {
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
cRGB c = getCrgbAt(idx);
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
::Focus.printColor(c.r, c.g, c.b);
|
|
|
|
Serial.println();
|
|
|
|
} else {
|
|
|
|
cRGB c;
|
|
|
|
|
|
|
|
c.r = Serial.parseInt();
|
|
|
|
c.g = Serial.parseInt();
|
|
|
|
c.b = Serial.parseInt();
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
setCrgbAt(idx, c);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case SETALL: {
|
|
|
|
cRGB c;
|
|
|
|
|
|
|
|
c.r = Serial.parseInt();
|
|
|
|
c.g = Serial.parseInt();
|
|
|
|
c.b = Serial.parseInt();
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
set_all_leds_to(c);
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case MODE: {
|
|
|
|
char peek = Serial.peek();
|
|
|
|
if (peek == '\n') {
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
Serial.println(get_mode_index());
|
|
|
|
} else if (peek == 'n') {
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
next_mode();
|
|
|
|
Serial.read();
|
|
|
|
} else if (peek == 'p') {
|
|
|
|
// TODO(algernon)
|
|
|
|
Serial.read();
|
|
|
|
} else {
|
|
|
|
uint8_t mode = Serial.parseInt();
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
set_mode(mode);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case THEME: {
|
|
|
|
if (Serial.peek() == '\n') {
|
|
|
|
for (uint8_t idx = 0; idx < LED_COUNT; idx++) {
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
cRGB c = getCrgbAt(idx);
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
::Focus.printColor(c.r, c.g, c.b);
|
|
|
|
::Focus.printSpace();
|
|
|
|
}
|
|
|
|
Serial.println();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint8_t idx = 0;
|
|
|
|
while (idx < LED_COUNT && Serial.peek() != '\n') {
|
|
|
|
cRGB color;
|
|
|
|
|
|
|
|
color.r = Serial.parseInt();
|
|
|
|
color.g = Serial.parseInt();
|
|
|
|
color.b = Serial.parseInt();
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
setCrgbAt(idx, color);
|
|
|
|
idx++;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
Major update of how LED modes work
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes #9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
7 years ago
|
|
|
}
|
|
|
|
|
|
|
|
kaleidoscope::LEDControl LEDControl;
|