Implements the `layer.on`, `layer.off`, and `layer.getState` commands, which can
be used to control the active layers from the host.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To be used in places where we have absolutely, positively no clue where a key
event came from, coordinate-wise.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Full documentation takes way too much space, and command names are a reasonable
compromise for discoverability.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Full documentation takes way too much space, and command names are a reasonable
compromise for discoverability.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Full documentation takes way too much space, and command names are a reasonable
compromise for discoverability.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Full documentation takes way too much space, and command names are a reasonable
compromise for discoverability.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Lift out the keyCode reading, event handling, and report sending into a small
helper function. Pretty much the same code has been called in a number of
different cases, lifting them out into a common helper improves clarity, and
reduces the size of the code, too.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The new step variants only use a one-byte argument, the `keyCode` part of a
`Key`, and they implicitly set flags to zero. This allows us to make macros even
more compact, by not having to use the flags when they are zero anyway.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of having to use a keydown & keyup step each time we tap a key, use a
combined event that does both. While this adds a tiny bit of code to
`Macros.play`, if our macros have many key taps (which by and large the most
common thing), we save a lot more. Three bytes per tap!
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This method uses the EEPROM only to augment the PROGMEM keymap: if EEPROM is
transparent, then PROGMEM is used. As such, the keymap in EEPROM is only an
overlay in this case.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Record the position of the first key pressed after going into the `WAIT_FOR_KEY`
state, but transition only when that key is released.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
We can't ++ enums in C++, it seems, so use a switch statement instead. Also
qualify the EEPROMKeymap object, so we call the object method, instead of trying
to call a method on a class as if it was an object. Oops.
Within this process, drop the END state, it is not required anymore.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The keymap.transfer command is only useful if we have both PROGMEM & EEPROM
keymaps, which will rarely be a case, and likely only temporarily, too. As such,
lift that out of the `focusKeymap` function, into its own. This makes the
command optional, and can save us some 140 bytes of program space (even more if
documentation is enabled).
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Jesse Vincent
Jesse Vincent
Gergely Nagy