caksoylar
commented
2 months ago 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);
}
kaievns
petejohanson
greg-hellings
lexxxel
miketronic
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 https://github.com/sadekbaroudi/zmk-fingerpunch-vik/pull/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/.