Add a `MACRODOWN` convenience macro, that will only run the given macro
when the key toggled on. It assumes that it is called from a function
with a `keyState` argument. If the key is not pressed, the macro will
evaluate to `MACRO_NONE`.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
`Dr`, `Ur`, and `Tr` are similar to the already existing `D`, `U`, and
`T` helpers, but they do not prefix their argument with `Key_`. This
makes it a lot easier to create macros that use custom key codes.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of calling loop hooks before anything else, including scanning
the matrix, call it after all that, at the end of `Keyboardio_::loop()`.
This is less surprising, and should not have any ill side-effects,
either.
(Based on a discussion with @obra on IRC.)
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Keys that have the IS_INTERNAL flag set can also have the same bit set as the
IS_MACRO bit, yet, we do not want to handle those as if they were macros. So
teach `handleMacroEvent` to skip keys with that bit set.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Since macros and other injected keys do not clear the report, we need a way to
release keys. The new `release_key` function does just that, similar to how
`press_key` does it for key presses. It is called by the default event handler
when the `keyState` toggles off, and has the `INJECTED` bit set.
The reason behind this is that keys that will need this special treatment will
always be injected keys. And those injected keys that do not need this
treatment, can be handled by an event handler prior to the default.
This should fix the macros not releasing keys issue.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of including `key_defs.h`, include `KeyboardioFirmware.h` in
`Keyboardio-MouseKeys.h`, so that the dependency is clear. This is
needed for the arduino-builder to arrange the linking order properly
when using KeyboardioFirmware, KeyboardioFirmware-MouseKeys and other
libraries combined. It does not affect the combination of just the two,
but if there's a third, that happens to include `KeyboardioFirmware.h`
too, this dependency is required for correct linking.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Use dot_a_linkage for the Keyboardio-Macros library, and as a
consequence, declare the Macros variable static instead of extern, so
that it gets compiled and linked in even when not referenced directly.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When we mark a symbol extern, but do not reference it anywhere else
directly, it will not be compiled in when using dot_a_linkage. For this
reason, make MouseKeys a static variable instead of extern.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of trying to include an uint16_t in an array of uint8_ts, add the flags
and the rawKey separately. Without this, macro playback would not work, because
the sequence would be corrupt.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The reason it was removed before no longer applies, and enabling it saves
noticeable amounts of size when using KeyboardioFirmware as a library.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The main thing here is `Macros_::play`, which takes a list of bytes from
PROGMEM, and plays a macro. The array is always a command, followed by
arguments, and the size of the argument depends on the command: key presses and
releases take a 16-bit argument, and the event is injected into the event
handler flow. Waiting and interval change take a 8-bit time. Helpers are
provided to make it a little bit easier to construct a macro.
Of course, the `macroAction` method may do any other side effects, and is not
restricted to returning a sequence of commands.
Fixes#5.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of hardcoding the macro actions into the core firmware, use a
`macroAction` function that is marked weak. This makes it possible to override
the function from Sketches, and implement the handlers there.
While there, also made sure that the `macroAction` is always called, with
`keyState` argument appropriately set. With this, macro actions can trigger on
keyup, or while held, or anytime the implementor wants, not just on keypress.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Because the animation saves if it has been run, it may do so during
factory testing. But running it every time is annoying, too. So as per
@obra's request, the code for the animation is kept, but removed from
the default sketch.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of having a previousState and a currentState, of which at most
two bits are used, use a single byte. This saves us a lot of code space,
and makes a number of things easier, too.
The helpers were redone as macros, since they are just bit checks now.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
They are not used anywhere, and as such, are a distraction. The states
will be reworked into something similar that was now dropped, but that's
a separate patch.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To make the code in the keyswitch state checking functions clearer, use
a macro instead of repeating the same constant everywhere.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of abusing `Key_NoKey`, use the new `INJECTED` flag in
`handle_key_event` and `handle_key_event_default` to check if the event
is an original, or an injected one.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The INJECTED flag can be used by handlers to determine where the event
originated from: as a result of a direct keypress, or if it was injected
into the event loop some other way.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When one adds or removes a layer from a keymap, the keymap size has to
be adjusted in the call to `Keyboardio.setup()`. This is easy to forget,
so as a helper, introduce `KEYMAP_SIZE`, a macro that automatically
computes the size at compile time.
This way, one does not need to remember to update the size anywhere.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The mousekeys are not specific to the Model01, name it after Keyboardio
instead, as suggested by @obra.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Save the seen state in EEPROM, so that the boot animation is displayed
only on first boot, and not every time the keyboard boots, or is plugged
in.
This way, we still have a nice welcome animation on first boot, but it
won't become an annoying delay every time the keyboard boots.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The primary reason for the move is to be able to disable mouse keys
completely, and not even compile them in. For this to work, it needs to
be in a separate library, otherwise it will always be included, even if
not active.
So, this patch turns mouse-keys into a simple plugin, included with the
core firmware! This makes the default event handler a bit simpler, the
code marginally smaller, and the feature completely optional.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
With the BootAnimation not functioning as a LED effect anymore, ship a
dedicated off effect.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Having the boot animation as a LED effect, making it function as an
"off" state, while a novel idea, is confusing. For this reason, make it
just a simple function we can call from the Sketch's `setup()` method.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
For those who'd like to work with C arrays, instead of generating
layouts from some other source, the `KEYMAP` macro makes it easier to
define a layer. The parameters in the macro arguments are arranged in
such a way that they can be formatted in a way that matches each hand
more closely. Similarly, a `KEYMAP_STACKED` is introduced, where the
hands are under each other, not side-by-side.
This is just aesthetics, for the C-savvier users.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
It would be nice if LED effects could be activated via their object, not
just their number, so that one could write - say, in a macro -
`myEffect.activate()`, and have it become the active mode.
To implement this, `LEDControl_` gains an `activate` method, that takes
a pointer, finds it in the mode array, and switches to its index (if
found). `LEDMode` gains an `activate` method too, which uses
`LEDControl`s new method of the same name to activate itself.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Gergely Nagy
Jesse Vincent
Jesse Vincent
Tim Neumann