The build-all command needs a clean(-ish) slate, and must re-set the build-dir,
otherwise a successful build of a previous plugin will remove it. As a
workaround, re-launch the builder in this case.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of counting loops for the purpose of calculating acceleration, use
timers and steps instead. This means that we can now tune how often the mouse
moves (`speedDelay`), how much it moves when it does (`speed`), how fast
acceleration is (`accelSpeed`), and how often we accelerate (`accelDelay`).
By default, the movement speed is one, and there is no delay, while acceleration
has an 50ms delay, and a speed of one.
But all of these can be tuned at run-time: we can turn off acceleration
completely, or slow down the mouse considerably - the possibilities are almost
endless!
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
With the recent speedup of the scan cycle, we need some delays for the animation
to look nice.
Fixes#2.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of always iterating through all layers, which slows us down
considerably, keep track of the highest active one, and start from there.
This has a VERY noticeable impact on the speed at which we finish a scan cycle.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Momentary layer switchers were broken, because they had the flags/keyCode parts
swapped. Apparently, I missed these when swapping the rest.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The function is broken, and does not belong here in the first place. It was a
remnant of how Akela was set up, but makes no sense in general.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Moved over the primary layer read/write code from KeyboardioFirmware, and
renamed them to `load_primary_layer`/`save_primary_layer`, because they deal
with layers, not keymaps now.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
It had the COLS & ROWS defines, which are hardware-specific, and were moved to
the hardware lib.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Moved all of the hardware-specific code to a separate library. As such, use the
special `KEYBOARDIO_HARDWARE_H` define to include the appropriate header, as set
by the board's `boards.txt`.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This is a library that implements the hardware-specific pieces for the
Keyboardio Model01, to be used with KeyboardioFirmware.
It's the same as `src/Model01.cpp`, `src/Model01.h`, `src/KeyboardConfig.cpp`,
`src/KeyboardConfig.h`, `src/utils.cpp`, and `src/utils.h` from
KeyboardioFirmware, merged into two files.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This works both when the hardware bits are still in KeyboardioFirmware, and when
lifted out, too.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When acting on `moveIntent`, set up the direction first, and move the cursor
only once, instead of twice (once for each axis). This makes the movement even
smoother, and also saves us a few bytes of code.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Move the hooks inside the `MouseKeys_` object, and drop the
`handle_mouse_key_event` function, by inlining it into the event handler hook.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of calculating separate acceleration for the x and y axes, use only a
single one, that applies to both axes. Thus, holding mouse up, and then pressing
and holding right will move the mouse cursor in a straight diagonal line,
instead of a curve.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of acting on mouse movement keys immediately in the event handler hook,
just store them, and act on them during a loop hook. This has the effect of
collecting all movement intents noticed in a full scan, and acting on them in
one go, rather than acting individually.
This makes diagonal movement (up & right keys pressed at the same time) a lot
smoother, at the cost of a few ms of delay. The delay is not noticeable, and the
smoothing would be a good trade anyway. No more jerky diagonal movements!
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>