|
|
|
#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;
|
|
|
|
uint16_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);
|
|
|
|
}
|
|
|
|
|
|
|
|
kaleidoscope::EventHandlerResult LEDMode::onSetup() {
|
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.mode_add(this);
|
|
|
|
setup();
|
|
|
|
|
|
|
|
return EventHandlerResult::OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
#if KALEIDOSCOPE_ENABLE_V1_PLUGIN_API
|
|
|
|
void LEDMode::begin() {
|
|
|
|
onSetup();
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
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) {
|
|
|
|
if (mode == 0) {
|
|
|
|
// wrap around
|
|
|
|
mode = LED_MAX_MODES - 1;
|
|
|
|
// then count down until reaching a valid mode
|
|
|
|
while (mode > 0 && !modes[mode]) mode--;
|
|
|
|
} else {
|
|
|
|
mode--;
|
|
|
|
}
|
|
|
|
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
|
|
|
|
kaleidoscope::EventHandlerResult LEDControl::onSetup() {
|
|
|
|
set_all_leds_to({0, 0, 0});
|
|
|
|
|
|
|
|
for (uint8_t i = 0; i < LED_MAX_MODES; i++) {
|
|
|
|
if (modes[i])
|
|
|
|
(modes[i]->setup)();
|
|
|
|
}
|
|
|
|
|
|
|
|
syncTimer = millis() + syncDelay;
|
|
|
|
|
|
|
|
return EventHandlerResult::OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
kaleidoscope::EventHandlerResult LEDControl::onKeyswitchEvent(Key &mappedKey, byte row, byte col, uint8_t keyState) {
|
|
|
|
if (mappedKey.flags != (SYNTHETIC | IS_INTERNAL | LED_TOGGLE))
|
|
|
|
return kaleidoscope::EventHandlerResult::OK;
|
|
|
|
|
|
|
|
if (keyToggledOn(keyState)) {
|
|
|
|
if (mappedKey == Key_LEDEffectNext) {
|
|
|
|
next_mode();
|
|
|
|
} else if (mappedKey == Key_LEDEffectPrevious) {
|
|
|
|
prev_mode();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return kaleidoscope::EventHandlerResult::EVENT_CONSUMED;
|
|
|
|
}
|
|
|
|
|
|
|
|
kaleidoscope::EventHandlerResult LEDControl::beforeReportingState(void) {
|
|
|
|
if (paused)
|
|
|
|
return kaleidoscope::EventHandlerResult::OK;
|
|
|
|
|
|
|
|
uint16_t current_time = millis();
|
|
|
|
if ((current_time - syncTimer) > syncDelay) {
|
|
|
|
syncLeds();
|
|
|
|
syncTimer += syncDelay;
|
|
|
|
}
|
|
|
|
update();
|
|
|
|
|
|
|
|
return kaleidoscope::EventHandlerResult::OK;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
::Focus.readColor(c);
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
::Focus.readColor(c);
|
|
|
|
|
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') {
|
|
|
|
prev_mode();
|
|
|
|
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;
|
|
|
|
|
|
|
|
::Focus.readColor(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
|
|
|
setCrgbAt(idx, color);
|
|
|
|
idx++;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Legacy V1 API
|
|
|
|
#if KALEIDOSCOPE_ENABLE_V1_PLUGIN_API
|
|
|
|
void LEDControl::begin() {
|
|
|
|
::LEDControl.onSetup();
|
|
|
|
Kaleidoscope.useEventHandlerHook(legacyEventHandler);
|
|
|
|
Kaleidoscope.useLoopHook(legacyLoopHook);
|
|
|
|
}
|
|
|
|
|
|
|
|
Key LEDControl::legacyEventHandler(Key mapped_key, byte row, byte col, uint8_t key_state) {
|
|
|
|
EventHandlerResult r = ::LEDControl.onKeyswitchEvent(mapped_key, row, col, key_state);
|
|
|
|
if (r == EventHandlerResult::OK)
|
|
|
|
return mapped_key;
|
|
|
|
return Key_NoKey;
|
|
|
|
}
|
|
|
|
|
|
|
|
void LEDControl::legacyLoopHook(bool is_post_clear) {
|
|
|
|
if (is_post_clear)
|
|
|
|
return;
|
|
|
|
::LEDControl.beforeReportingState();
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
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;
|