feat(mouse): Add mouse move and scroll support #2477
Conversation
petejohanson
added
enhancement
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
from
e90e11d to
7e9f046
Compare
|
It looks like there is a bug in ticks->ms conversions in mouse keys that break acceleration behavior; these fixes got acceleration working again for me: diff --git a/app/src/behaviors/behavior_input_two_axis.c b/app/src/behaviors/behavior_input_two_axis.c
index 20f5d52a..dd2f3bf6 100644
--- a/app/src/behaviors/behavior_input_two_axis.c
+++ b/app/src/behaviors/behavior_input_two_axis.c
@@ -112,7 +112,7 @@ static float speed(const struct behavior_input_two_axis_config *config, uint16_t
float max_speed, int64_t duration_ticks) {
uint8_t accel_exp = get_acceleration_exponent(config, code);
- if ((duration_ticks * CONFIG_SYS_CLOCK_TICKS_PER_SEC / 1000) > config->time_to_max_speed_ms ||
+ if ((1000 * duration_ticks / CONFIG_SYS_CLOCK_TICKS_PER_SEC) > config->time_to_max_speed_ms ||
config->time_to_max_speed_ms == 0 || accel_exp == 0) {
return max_speed;
}
@@ -123,8 +123,8 @@ static float speed(const struct behavior_input_two_axis_config *config, uint16_t
return 0;
}
- float time_fraction = (float)duration_ticks * CONFIG_SYS_CLOCK_TICKS_PER_SEC /
- config->time_to_max_speed_ms / 1000;
+ float time_fraction = (float)(1000 * duration_ticks / CONFIG_SYS_CLOCK_TICKS_PER_SEC) /
+ config->time_to_max_speed_ms;
return max_speed * powf(time_fraction, accel_exp);
} |
| &mmv MOVE_DOWN | ||
| ``` | ||
|
|
||
| The following will send a scroll left event to the host when pressed/held: |
There was a problem hiding this comment.
"scroll" should be "mouse move" here and in line 90, I think.
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
3 times, most recently
from
2052d19 to
4fc6861
Compare
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
7 times, most recently
from
4fed437 to
d1a09bb
Compare
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
from
d1a09bb to
447afcb
Compare
|
just fyi, I used this in a custom build and it seems to be working just fine, thanks! https://github.com/kaievns/little-wing/blob/6ce99b4b3827adb583cbbd0d54b5616a0b304c66/zmk-config/config/little_wing.keymap#L27C1-L44C7 a built in mouse to wheel mapper would be a good idea I reckon, i stole mine from badjeff's work |
I added a preconfigured code mapper for this today. After |
|
I've just given it a go and it works perfectly for me. I've also noticed that you've added the two-axis to mouse scroll |
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
2 times, most recently
from
a6cb056 to
032f421
Compare
|
I was using your previous branch, and I switched to this one. So far it's working great for me with just basic mouse move emulation and scroll on the key bindings. However, the speed of the scroll is wickedly fast compared to the scrolling speed on your previous branch. Almost too quick to keep up with in most cases. |
|
@petejohanson |
|
hey @petejohanson i think there is something fishy going on with the Long story short I'm building a split keyboard with a trackball and I followed your work that someone in discord pointed me to over here https://github.com/sadekbaroudi/zmk-fingerpunch-vik/pull/1/files and i have adopted it over here https://github.com/kaievns/little-wing/blob/6aaabf9901a5721276f37030116f5688fcd68fa0/zmk-config/boards/shields/little_wing/little_wing_right.overlay#L11-L35 If I set the left side as central and the right one (the one with a trackball) as a periferal side, it compiles and works great via USB, but in case of bluetooth connection I think there is lag + interference as data is fed from right to left and then to a PC, and that leads to some very jumpy and unstable cursor movements. And kind of unusable tbh. But, if i try to set the right side as the central one--so that data would go straight to the PC--, it doesn't compile. The left side says that the and the right side compiles but fails at the linking stage which looks like some sort of device ordering issue. thought I'd share it, feel free to ping me on discord if you'd want to dig into it |
|
This is a great update; simple to implement, the scrolling is fantastic -- so smooth! Is there a way to specify cursor speed? Also, are there any options for acceleration such as ramping up to full speed after X ms? |
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
from
4b54648 to
e28a83d
Compare
|
FYI: After a massive amount of various small fix commits, I've rebased against latest |
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
from
e28a83d to
15c0155
Compare
| --- | ||
| title: Pointing Devices | ||
| sidebar_label: Pointers | ||
| --- |
There was a problem hiding this comment.
I think I would split this page into a pair of tabs, one for "Unibody or Split Central" (with a better name) and one for peripheral. I would extract the "input device" section into a different file, so that you can import it into both tabs for clarity reasons.
There was a problem hiding this comment.
I took a stab at this. I decided not to create any "shared docs" bit, since the specifics/flow was just subtly different enough it would have led to a more awkward end result in the docs. LMK what you think.
docs/docs/features/pointers.md
Outdated
| ## Input Listeners | ||
|
|
||
| Listeners are the key piece that integrate the low level input devices to the rest of the ZMK system. In particular, listeners subscribe to input events from the linked device, and when a given event occurs (e.g. X/Y movement), apply any input processors before sending those events to the HID system for notification to the host. The main way to modify the way a pointer behaves is by configuring the input processors for a given listener. | ||
|
|
||
| For more details on assigning processors to your listeners, see the [input processor usage](../keymaps/input-processors/usage.md) documentation. |
There was a problem hiding this comment.
I don't think this information is user-end. I think this would be more suitable in hardware integration, with perhaps a short note in the usage page.
There was a problem hiding this comment.
Since input listeners are the thing that end users will be assigning processors to, I felt it important to briefly describe them here.
There was a problem hiding this comment.
Im not 100% sold, but leave it here for the time being and Ill argue my case on the second pass.
| #### `trigger-period-ms` | ||
|
|
||
| How many milliseconds between generated input events based on the current speed/direction. | ||
|
|
||
| #### `delay-ms` | ||
|
|
||
| How many milliseconds to delay any processing or event generation when first pressed. | ||
|
|
||
| #### `time-to-max-speed-ms` | ||
|
|
||
| How many milliseconds it takes to accelerate to the curren max speed. | ||
|
|
||
| #### `acceleration-exponent` | ||
|
|
||
| The acceleration exponent to apply, with three possible values: | ||
|
|
||
| - `0` - uniform speed | ||
| - `1` - uniform acceleration | ||
| - `2` - exponential acceleration |
There was a problem hiding this comment.
I feel like these should all be in the code block with examples, and then a table to present this information below.
There was a problem hiding this comment.
Switched this around. LMK what you think.
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
from
efa0219 to
6fdf192
Compare
|
Rebased to fix up merge conflict after the merge of #2537 |
|
|
||
| The details will depend on if you are adding a pointing device to a [split peripheral](../../features/split-keyboards.md#central-and-peripheral-roles) or to a non-split or split central: | ||
|
|
||
| <Tabs |
There was a problem hiding this comment.
I think my general suggestion on this point would be to get the headers "Input Device", "Listener", and "Input processor" outside of the tabs using the invisible tabs trick. Then change the max header depth on the sidebar so that the subheaders of "listener" under the split section aren't visible.
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
2 times, most recently
from
5c6be5e to
f402ff0
Compare
Add new remote for experimental branch zmkfirmware/zmk#2477
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
2 times, most recently
from
efd6434 to
a072dd7
Compare
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
from
68692d5 to
ecb2005
Compare
* Use Zephyr input subsystem for all pointers. * Input processors for modifying events, e.g. scaling, swapping codes, temporary (mouse) layers, etc. * Mouse move/scroll behaviors. * Infrastructure in place for physical pointer input devices. Co-authored-by: Alexander Krikun <[email protected]> Co-authored-by: Robert U <[email protected]> Co-authored-by: Shawn Meier <[email protected]> Co-authored-by: Chris Andreae <[email protected]>
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
from
ecb2005 to
0ddce94
Compare
Co-authored-by: Anant Thazhemadam <[email protected]> Co-authored-by: Erik Tollerud <[email protected]> Co-authored-by: Cem Aksoylar <[email protected]> Co-authored-by: Nicolas Munnich <[email protected]>
petejohanson
force-pushed
the
feat/pointers-with-input-processors
branch
from
0ddce94 to
116e2ea
Compare
Summary
This is the planned successor to #2027 that integrates a more flexible input processing system inspired by the work by badjeff. I will leave #2027 alone for now, but this PR is intended to be the version that's targeted to actually merge.
WARNING The work in this PR is subject to ZERO API/code/config stability guarantees. If you want something that won't randomly break on you, keep using #2027. Only use the branch from this PR if you are willing to accept that, follow the PR closely for any changes, and are technical enough to solve any problems that occur from using it.
Input Processors
All the options for scaling, swapping X/Y values, etc are now accomplished with input processors, that can be set on a given listener, and overridden for a set of given layers:
I've implemented input processors with the following compatible values:
zmk,input-processor-code-mapper- For translating input codes to other values. Useful for enabling a "scroll layer" that makes a pointer send scroll events instead of X/Y move events.zmk,input-processor-scaler- For scaling values, using a passed in multiplier and divisor. Useful for "precision layer". Example&vip_xy_scaler 1 4to scale values by 1/4, for fine grained movements.zmk,input-processor-temp-layer- For enabling a layer until a certain time period of no input events from the device. Useful for a "mouse layer" with mouse keys when using an integrated trackpad/ball/whatever.zmk,input-processor-transform- For swapping X/Y values, inverting a given Y or X value. Useful when a given input driver doesn't support these transforms and it may be installed rotated 90deg, etc.Input processors are tied to input listeners, with layer overrides, e.g.:
Smooth Scrolling
This also adds "smooth scrolling" support, by using HID "resolution multipliers", which appears to be supported in Linux and Windows, but not macOS. On macOS, we should be properly falling back to normal behavior here even with
CONFIG_ZMK_MOUSE_SMOOTH_SCROLLING=y. More testing needed here.Split
This PR includes a second commit to add split input device support. You can see an example PR implementing a split Cirque controller at sadekbaroudi/zmk-fingerpunch-vik#1
The key new driver here is behind the
zmk,input-splitcompatible value. This driver has different modes based on being used on a split peripheral or central. When used on a peripheral, this acts as a listener for the specified input events on the referenced device, and forwards those events to the central (after some optional peripheral side input processing that can be used to clean up rotation, etc. beforehand). On the central, this driver registeres it's own input device, that should have a ZMK input listener added referencing it. The driver will receive the events from the peripheral and fire them locally for processing.Testing
So far, I've tested with mouse keys/scroll/move, and with a Cirque device. More testing all around! Existing generic Zephyr input devices should still "just work" with this PR.
To Do
/omit-if-no-ref/.