From an earlier version of the b2c patches, before meson-build.sh got
updated to do what's required here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This hurts more than it helps, and users complain of dead trackpad
edges. Apple touchpads have fairly sophisticated internal palm rejection
algorithms going back many years, so let's just disable this one on
everything Apple.
Related to: #433 (need to figure out what other hardware may need this)
Signed-off-by: Hector Martin <marcan@marcan.st>
Right now for touch arbitration to work, we require the device group to
be the same (i.e. they're hanging off the same physical bus). That's not
always the case and statistically we have a lot more devices that have
a built-in tablet + touchscreen than we have Intuos-like external
tablets.
So let's default to the more common case - enabling arbitration with the
first touchscreen/external touchpad we find. If a subsequent device is
"better", swap it out. Right now, the only heuristic we have here is the
device group check but in the future we could get more precise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The key_count array for buttons records the logical button sent to the
client - for left-handed configurations that means a BTN_LEFT is
recorded as BTN_RIGHT.
When the device is suspended and we are releasing all keys we must thus
release the button code as-is without trying to map it again.
Fixes#881
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This version includes the (possible) fix for our CI picking up the wrong
range in the commit checks and failing the pipeline.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A whitespace fix, moving a check-related #define closer to the #include
and change a test that doesn't need a device to litest_add_no_device().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Like in libinput_device_switch_has_switch()'s documentation, document
the error case in libinput_device_tablet_pad_get_num_buttons(),
libinput_device_tablet_pad_get_num_rings() and
libinput_device_tablet_pad_get_num_strips().
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Now that we're Python ConfigParser compatible (again), we can check our
quirks file for things our actual parser doesn't care about, but that we
should honour. Right now that means that bustypes and vid/pid matches are
all spelled consistently.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is confusing without any explanation - the first set of touches is
within the edge zone, the second set of touches is explicitly within the
software button area but not inside the edge zone. Let's add comments so
the intention is clear.
Same-ish for the clickfinger test.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our parser doesn't care about this, but let's stick to the proper format so
we can read those files with e.g. Python's ConfigParser
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This way we can rely on physical coords on this screen being actually
meaningful. Not currently in use but future tests will use this touch
device as generic screen.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The commit fixes linebreaks at the end of the files for files generated
with ci-fairy generate-templates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Adds a dedicated scroll movement type to the custom acceleration profile.
Supported by physical mouse and touchpad.
Other profiles remain the same by using the same unaccelerated filter for the scroll filter.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
The keyboard present on this device is not recognized as internal and
disable while typing does not work.
Add a quirk to fix this feature.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/848
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This shouldn't have functional changes because MESON_TEST_ARGS was set
for all our b2c/qemu tests and thus the tests would run automatically.
To make this script more generic, specify --run-test explicitly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The `speed_factor()` formula is unnecessarily complex, The behavior that is described in the comment can be achieved with a simple power function.
And adjust the comment to explicitly state that 0.05 is the minimum.
Previously the arbitration rectangle would be moved to lie completely in
the first quadrant of the coordinate system.
Signed-off-by: hrdl <51402-hrdl@users.noreply.gitlab.freedesktop.org>
For the cases where it's not possible to hit enter to start the replay
because e.g. we cannot change focus, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Adds min and max size limit for custom acceleration function's points.
Adds tests to make sure validation works properly.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
WARNING: extlinks: Sphinx-6.0 will require a caption string to contain
exactly one '%s' and all other '%' need to be escaped as '%%'.
Well, let's do that then!
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
