|
|
|
/* Kaleidoscope-LEDControl - LED control plugin for Kaleidoscope
|
|
|
|
* Copyright (C) 2017-2018 Keyboard.io, Inc.
|
|
|
|
*
|
|
|
|
* This program is free software: you can redistribute it and/or modify it under
|
|
|
|
* the terms of the GNU General Public License as published by the Free Software
|
|
|
|
* Foundation, version 3.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
|
|
|
|
* FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
|
|
|
|
* details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
* this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "Kaleidoscope-LEDControl.h"
|
|
|
|
#include "Kaleidoscope-FocusSerial.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 {
|
|
|
|
namespace plugin {
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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) {
|
|
|
|
if (!Kaleidoscope.has_leds)
|
|
|
|
return;
|
|
|
|
|
|
|
|
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 (int8_t i = 0; i < LED_COUNT; i++) {
|
|
|
|
setCrgbAt(i, color);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void LEDControl::setCrgbAt(int8_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);
|
|
|
|
}
|
|
|
|
|
|
|
|
cRGB LEDControl::getCrgbAt(int8_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) {
|
|
|
|
if (paused)
|
|
|
|
return;
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
// unsigned subtraction means that as syncTimer rolls over
|
|
|
|
// the same interval is kept
|
|
|
|
uint16_t elapsed = Kaleidoscope.millisAtCycleStart() - syncTimer;
|
|
|
|
// on some platforms, the subtraction in the comparison results in a signed
|
|
|
|
// operation, resulting in syncLeds() no longer getting called.
|
|
|
|
if (elapsed > syncDelay) {
|
|
|
|
syncLeds();
|
|
|
|
syncTimer += syncDelay;
|
|
|
|
}
|
|
|
|
update();
|
|
|
|
|
|
|
|
return kaleidoscope::EventHandlerResult::OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
EventHandlerResult FocusLEDCommand::onFocusEvent(const char *command) {
|
|
|
|
enum {
|
|
|
|
SETALL,
|
|
|
|
MODE,
|
|
|
|
AT,
|
|
|
|
THEME,
|
|
|
|
} subCommand;
|
|
|
|
|
|
|
|
if (!Kaleidoscope.has_leds)
|
|
|
|
return EventHandlerResult::OK;
|
|
|
|
|
|
|
|
if (::Focus.handleHelp(command, PSTR("led.at\n"
|
|
|
|
"led.setAll\n"
|
|
|
|
"led.mode\n"
|
|
|
|
"led.theme")))
|
|
|
|
return EventHandlerResult::OK;
|
|
|
|
|
|
|
|
if (strncmp_P(command, PSTR("led."), 4) != 0)
|
|
|
|
return EventHandlerResult::OK;
|
|
|
|
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 EventHandlerResult::OK;
|
|
|
|
|
|
|
|
switch (subCommand) {
|
|
|
|
case AT: {
|
|
|
|
uint8_t idx;
|
|
|
|
|
|
|
|
::Focus.read(idx);
|
|
|
|
|
|
|
|
if (::Focus.isEOL()) {
|
|
|
|
cRGB c = ::LEDControl.getCrgbAt(idx);
|
|
|
|
|
|
|
|
::Focus.send(c);
|
|
|
|
} else {
|
|
|
|
cRGB c;
|
|
|
|
|
|
|
|
::Focus.read(c);
|
|
|
|
|
|
|
|
::LEDControl.setCrgbAt(idx, c);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case SETALL: {
|
|
|
|
cRGB c;
|
|
|
|
|
|
|
|
::Focus.read(c);
|
|
|
|
|
|
|
|
::LEDControl.set_all_leds_to(c);
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case MODE: {
|
|
|
|
char peek = ::Focus.peek();
|
|
|
|
if (peek == '\n') {
|
|
|
|
::Focus.send(::LEDControl.get_mode_index());
|
|
|
|
} else if (peek == 'n') {
|
|
|
|
::LEDControl.next_mode();
|
|
|
|
} else if (peek == 'p') {
|
|
|
|
::LEDControl.prev_mode();
|
|
|
|
} else {
|
|
|
|
uint8_t mode;
|
|
|
|
|
|
|
|
::Focus.read(mode);
|
|
|
|
::LEDControl.set_mode(mode);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case THEME: {
|
|
|
|
if (::Focus.isEOL()) {
|
|
|
|
for (int8_t idx = 0; idx < LED_COUNT; idx++) {
|
|
|
|
cRGB c = ::LEDControl.getCrgbAt(idx);
|
|
|
|
|
|
|
|
::Focus.send(c);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
int8_t idx = 0;
|
|
|
|
while (idx < LED_COUNT && !::Focus.isEOL()) {
|
|
|
|
cRGB color;
|
|
|
|
|
|
|
|
::Focus.read(color);
|
|
|
|
|
|
|
|
::LEDControl.setCrgbAt(idx, color);
|
|
|
|
idx++;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return EventHandlerResult::EVENT_CONSUMED;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
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::plugin::LEDControl LEDControl;
|
|
|
|
kaleidoscope::plugin::FocusLEDCommand FocusLEDCommand;
|