While we do clear the report every cycle, similar to how key release events are
explicitly removed from the report, mouse movements should get removed too. This
makes it possible to use them in macros reliably, without surprising results (an
extra report sent at the end of the macro).
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This warp mode is similar to the navigation provided by some speech
recognition software. A 9-cell grid may provide more precision and
efficiency than the existing 4-cell warp mode. This adds some extra
key definitions to support the additional sectors and enables a user
to switch the grid size:
MouseKeys.setWarpGridSize(MOUSE_WARP_GRID_3X3);
Signed-off-by: Cy Rossignol <cy@rossignols.me>
Before this change, we couldn't use the full functionality of the plugin's
warp feature to drag an item (by holding down a mouse button key). The
plugin would reset the warp state during each scan cycle, so we could
only warp the pointer to a cell in the top-level grid. This fix enables
warping repeatedly into sub-cells while holding a mouse button.
Since we switched to using a separate node for the absolute mouse, it works with
all three major operating systems. For that reason, the note about OS
compatibility is incorrect, and with this patch, we drop it.
Reported by @noseglasses, thanks!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of discrete press & release tracking, press the mousekey when the
physical key is pressed, and like `Keyboard`, send & clear the report once per
cycle, instead on every action.
This fixes#10.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Use `Kaleidoscope.useEventHandlerHook` and `Kaleidoscope.useLoopHook` instead of
the deprecated `event_handler_hook_use` and `loop_hook_use` interfaces.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Uses mickeys (1/16th subpixel units) now instead of pixels. Much smoother!
Added "speedLimit" config var to set maximum cursor speed.
Ensured default values are sane.
To avoid issues with static initialization order, move the Mouse & AbsoluteMouse
initialization from the MouseWrapper constructor to MouseWrapper.begin, which
will be called from MouseKeys.begin. Thus, user code does not need to change.
This fixeskeyboardio/Kaleidoscope#140.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
With these changes, the vertical scrolling of the mouse wheel is now properly
supported. It has no acceleration, because the wheel doesn't have one either. It
has a delay, however, which I tried to tune to a reasonable speed.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
WARP + Button makes no sense together, so reuse the _BUTTON bit for _WARP_END.
This will allow us to use the free'd up bit for something else.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of calculating time deltas every time we want to check a
timeout, calculate the projected end ahead of time.
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>
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>
Gergely Nagy
Gergely Nagy
Ryan Anderson
Jesse Vincent
Cy Rossignol
SjB
Gergely Nagy
Craig Disselkoen
Jesse Vincent
Selene Scriven
Gergely Nagy