The generic quirk introduced in commit d1f274c781 ("quirks: add a
more generic match for the 5288 Synaptics clickpad") affects the
touchpad (with physical buttons) present in the Positivo-Vaio.
Fixes#819
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This switches the quirk from AttrEventCodeEnable/Disable to just
AttrEventCode with a +/- prefix for each entry.
This switches the quirk from AttrInputPropEnable/Disable to just
AttrInputProp with a +/- prefix for each entry.
Previously, both event codes and input props would only apply the
last-matching section entry for a device. Furthermore, an earlier Disable entry
would take precedence over a later Enable entry. For example, a set of
sections with these lines *should* enable left, right and middle:
[first]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;BTN_MIDDLE
[second]
AttrEventCodeDisable=BTN_RIGHT
[third]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;
Alas: the first line was effectively ignored (quirks only returned the
last-matching one, i.e. the one from "third"). And due to implementation
details in evdev.c, the Disable attribute was processed after Enable,
i.e. the device was enabled for left + right and then disabled for
right. As a result, the device only had BTN_LEFT enabled.
Fix this by changing the attribute to carry both enable/disable
information and merging the commands together.
Internally, all quirks matching a device are simply ref'd into an array
in the struct quirks. The applied value is simply the last entry in the
array corresponding to our quirk.
For AttrEventCode and AttrInputProp instead do this:
- switch them to a tuple with the code as first entry and a boolean
enable/disable as second entry
- if the struct quirk already has an entry for either, append the more
recent one to the existing entry (instead of creating a new entry in
the array). This way we have all entries that match and in-order of
precedence - i.e. we can process them left-to-right to end up
with the right state.
Fixes: https://gitlab.freedesktop.org/libinput/libinput/-/issues/821
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A user was experiencing issues with their hand being recognized as
touch input above the stylus tip.
Since touch above the stylus should be rare, increase the touch
arbitration rectangle height by 50mm.
Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/809
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
When compiling with Sparse enabled:
$ CC=cgcc meson builddir
Fix warnings about variables that should be made static.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix the warnings generated:
[232/243] Compiling C object libinput-test-suite.p/test_test-pad.c.o
../test/test-pad.c:211:3: warning: variable 'count' is uninitialized
when used here [-Wuninitialized]
count++;
^~~~~
../test/test-pad.c:261:3: warning: variable 'count' is uninitialized
when used here [-Wuninitialized]
count++;
^~~~~
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix the warning generated:
[129/243] Compiling C object libinput-test-suite.p/test_test-touchpad.c.o
../test/test-touchpad.c:2679:1: warning: unused
function 'touchpad_has_rotation' [-Wunused-function]
touchpad_has_rotation(struct libevdev *evdev)
^
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix the warning generated:
[82/243] Compiling C object libinput.so.10.13.0.p/src_evdev-tablet.c.o
../src/evdev-tablet.c:938:1: warning: unused function
'tool_set_bits_from_libwacom' [-Wunused-function]
tool_set_bits_from_libwacom(const struct tablet_dispatch *tablet,
^
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix warning building with Clang v15:
../test/test-pad.c:334:15: warning: variable 'expected_number'
set but not used [-Wunused-but-set-variable]
unsigned int expected_number = 0;
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Apple M2 (and presumably newer) laptops now embed the touchpad
controller into the main SoC, and use a new internal communications
protocol between it and the main CPU. This isn't really a "bus" like
SPI or I2C, so the downstream kernel driver currently uses the (not
well supported) HOST bus type. MatchBus can't match on that, so let's
just use a name match (plus the vendor ID, which is still valid and
the usual Apple one).
Signed-off-by: Hector Martin <marcan@marcan.st>
Unlikely we'll ever have the docs fully translated (or translated at
all...) anyway.
Fixes "WARNING: Invalid configuration value found: 'language = None'.
Update your configuration to a valid language code. Falling back to 'en'
(English)."
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Running "dnf install" during a job can lead to issues when the image is
old - package renames/replacements/etc. may require a dnf upgrade to get
those packages sorted first before our dnf install works.
This hasn't been a problem for us because we had weekly rebuilds of the
images scheduled and were usually on the latest package set but let's do
this properly anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This gets rid of of the following error:
ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found
Too tired to debug what is really going on, so let's pretend the update
is the best way to fix this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The escape key can be used to cancel a drag and drop action in some
desktop environments. However, it triggers disable-while-typing, ending
the drag and drop action rather than cancelling it.
Add it to the tp_key_ignore_for_dwt() set to avoid it.
Since I'm here, add the asterisk key as it is the only numpad key not
ignored by tp_key_ignore_for_dwt().
Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/820 # [1]
Suggested-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The ck_assert_ptr_null() function is not available in the version of
the check library included in 20.04 LTS Focal (0.10.0).
Use ck_assert_ptr_eq() to avoid compilation errors.
Fixes: eeae8906db ("util: return the number of elements from strv_from_string")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
On Sway, and probably other Wayland compositors based on wlroots, the
window_lock_pointer() was called twice.
Avoid errors when window_lock_pointer() is invoked multiple times.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/808
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Some distributions, like Fedora, compile libinput with the debug-gui
option set to false.
Running "libinput debug-gui" indicates that the program is not
installed; however, the help message suggests that the command is
available.
Hide debug-gui from the help message when it is not included.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/480
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
In commit 6a1bd5b0c9 ("meson.build: check gtk targets before
building") introduced a custom config option to check whether Wayland
is supported by GTK or not.
However, in some cases the config option is not set generating this
warning:
../tools/libinput-debug-gui.c:51:5: warning: "HAVE_GTK_WAYLAND" is
not defined, evaluates to 0 [-Wundef]
51 | #if HAVE_GTK_WAYLAND
| ^~~~~~~~~~~~~~~~
Make sure to always set HAVE_GTK_WAYLAND.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Commit 806d4a1393 ("tablet: check libevdev_get_abs_info() return
value") prevented a crash when tilt was deactivated by a quirk.
For more information check [1].
Add similar checks before calling libevdev_get_abs_info() to avoid
possible crashes.
[1] https://gitlab.freedesktop.org/libinput/libinput/-/issues/805
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Removes a colon from frameworks quirks dmi match
so it matches pnLaptop(12thGenIntelCore) on newer model
Signed-off-by: Tadhg McDonald-Jensen <tadhgmister@gmail.com>
Commit b5f0536a4f ("quirks: add a quirk for the Wacom 524c device")
added the quirk "AttrEventCodeDisable=ABS_TILT_X;ABS_TILT_Y;" to the
Wacom 524c.
When using the pen in a display with tilt support, the tilt X/Y axes
are set as changed. Using the pen again, but this time in the display
without tilt support, will try to get the tilt information, crashing.
Check the return value of libevdev_get_abs_info() to avoid this crash.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/805
Fixes: b5f0536a4f ("quirks: add a quirk for the Wacom 524c device")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Previously, trackpoints got assigned the normal flat profile which does not
accommodate for the trackpoint magic multiplier *and* had a config range
that was too small if you take the multiplire indo account anyway.
Fix this by adding a trackpoint-specific flat accel that has a wider
configuration range and take sthe magic multiplier into account.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Users that want a flat pointer acceleration want the input speed to
match 1:1 to the output speed, barring a fixed constant multiplier.
This will apply to things like button scrolling as well, so let's map
the constant accel function to the non-constant accel functions to the
speed setting applies to every movement.
This is applied to both the flat and the touchpad flat filter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first thing this filter does is normalize the coordinates to
1000dpi, i.e. all other values are in normalized coordinates.
By normalizing the speed again we get an invalid value, effectively
stretching or compressing the acceleration curve. e.g. on a 5000dpi
mouse the estimated speed was 1/5 of the real speed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our pointer filter code has two functions - one for accelerated movement
and one for "constant" movement (i.e. no accel factor provided but same
conversions). Let's use that instead of a manual normalization.
This fixes an issue with button scrolling on high-dpi mice in the flat
pointer acceleration: normal pointer motion in the flat profile isn't
normalized but the button scrolling was - resulting in e.g. 5 times
slower motion for button scrolling on a 5000dpi mouse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The filter vs const filter is supposed to be for accelerated vs
non-accelerated motion (e.g. pointer motion vs scrolling) - in both
cases the returned value is supposed to be in the same coordinate
system, just once with an extra accel factor applied.
This was broken in the flat and low-dpi profiles: in both of those the
accelerated filter does *not* normalize, it merely applies the fixed/adaptive factor.
The constant filter normalized however. The result was that on e.g. a
5000dpi mouse the constant motion was 5 times slower than the
accelerated motion, even with a factor of 1.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a leftover from when some of the filter code was shared between
pointer acceleration methods (pre v1.11 or so). Now these functions are
duplicated across files, so both the names and what they do isn't
necessarily reflective anymore.
Let's drop one layer of indirection to make the code a bit easier to
understand.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, this is just for improving readability and a
leftover when some of these functions were used by multiple filters.
This filter normalizes the data first, then applies the acceleration to
the normalized values. So let's keep the data in normalized_coords
structs and only drop to device_float_coords when we have to to use the
tracker API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Too many timing-related failures with 4 or (the default) 8 jobs, clearly
our runners aren't fast enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Looks like we are having clock skew issues on qemu, so given that
we just need qemu in the image, we can compile on the host (reliable)
and then only start the tests in qemu.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This will allow us to have the udevadm tool and systemd-udevd available
while running inside qemu
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This allows us to not have to create a specific image, and also
should be more reliable because we don't have to boot a full distribution
each time we just start our test suite.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
I am pretty sure this one guard is a leftover from a previous version.
That is because use_for_custom_build_tests is true when
use_for_qemu_tests is, so probably a useless test here.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
