Having it at the brightest uses too much power, and may result in power use
surges when switching between LED modes and NumPad, which in turn can force the
operating system to disable the whole device. To avoid this, lower the
brightness to 160, a carefull tuned value, also used by the `solidRed` mode in
the factory firmware.
Fixes#9.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This avoids the OS being stuck with Numlock on, which leaves the LED on
if other keyboard are attached, and breaks FVWM.
See keyboardio/Model01-Firmware#42
Instead of trying to track numlock ourselves, rely on the host telling us what
it thinks the state is. This is much more reliable than what we were doing, and
hopefully fixes most of - if not all - the issues we were having with NumLock.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Requiring the end-user to use a macro to have the NumLock effect is a bit
confusing. We can do better than that, by using an event handler hook, and
catching `Keypad_NumLock` presses, and toggle on keypress.
This way, the macro is not necessary, and all the user has to do, is to use the
plugin, configure `numPadLayer`, and done.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Instead of trying to exclude layer keys, exclude everything with a flag. Thus,
only the basic keys will receive the highlighting treatment, and the rest,
`Prog`, `Any` and the layer keys will not.
Thanks to @chughes87 for the report!
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
As there are - or at least may be - other keys on the layer, not just NumPad
ones, those should be highlighted too.
Addresses the bulk of keyboardio/Kaleidoscope#149, by comparing the looked up
key with what is directly on the `numPadLayer`: if they are the same, then it is
a key that we assume changed, and do the coloring. If they are different (in
other words, the key on the `numPadLayer` is transparent or off), we skip the
highlight.
The downside is that we highlight layer switching keys too, which we may not
want. That will be addressed separately.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of requiring the NumLock key row and column, and the numpad layer index
to be passed to `NumLock.toggle` on every call, derive the first two from
Macros.row and Macros.col respectively, and the latter from a new class
variable, which should be set in the `setup()` method of the sketch.
This way, `NumLock.toggle()` becomes argument-less.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To make sure that the active LED mode is restored to a good state, re-init it.
Without this change, LED modes that do all their work in the `init()` method
will not refresh when NumLock is turned off.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Having the LED effects of the NumLock layer as a special LED mode has a number
of drawbacks, like not interacting well with led mode switching: one can't get
back to the NumLock effect once switching away from it (but the mode remains
active nevertheless).
To avoid this and other issues, don't make the effect a LED mode. Instead,
override the active LED mode with the numlock layer colors. This way, it is
always in sync with the layer.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
`TOGGLENUMLOCK` is the index of the macro, to be used in the `macroAction`
function, and `Key_ToggleNumlock` is to be used in the keymap, instead of
`M(0)`. This is considerably friendlier than before.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
First of all, to disallow switching to LEDNumlock, we need to do the check in
the `.init()` method, not in `.setup()`. Second, tracking the previous LED mode
can be done a lot simpler - and a lot reliably.
With these changes, the NumLock LED effect works as it is expected to.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Gergely Nagy
Gergely Nagy
Maxime de Roucy
Marty Gentillon
Evan Danaher
Jesse Vincent
Gergely Nagy
Gergely Nagy