destroy isn't called until the last libinput_device_unref(), so we may trigger
a debounce timer after the device was removed. The same fix is neded for the
touchpad interface.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/72
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The tapping code can handle palm states now, so there is no need to disable
tapping altogether when a tool-based palm is detected.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/65
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Removed from the udev properties in a55693f87c
but survived here while the branch was in process.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The ssize_t cast upsets coverity for some reason but we can be a lot more
restrictive here anyway. Quick analysis of the zalloc calls in the test suite
show the largest allocation is 9204 bytes.
Let's put a cap on for one MB, anything above that is likely some memory
corruption and should be caught early.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Matheus Santana <embs@cin.ufpe.br>
The values are the same and this is ABI so they will never change. Make the
cast explicit for coverity's benefit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ignore motion when pressure/touch size fell below the threshold, thus
ending the touch.
Real world significance: subjectively scrolling/cursor positioning with
a touchpad now a bit better on SAMSUNG NP305V5A laptop.
https://gitlab.freedesktop.org/libinput/libinput/merge_requests/4
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Nothing in libinput needs large buffers, so if we ever get something that
large, we probably passed a negative number to zalloc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make it return NULL for a string array in the form of [ NULL ], like the docs
say. This also adds an extra safety check for the joiner to be of a reasonable
length to avoid overflows.
Found in
https://gitlab.freedesktop.org/libinput/libinput/issues/26#note_6320
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A bit quirky (haha), because we cannot do this during context creation - we
really want any parsing error messages to show up in the right log file and
the log handler isn't set up during context creation. So we do it on the first
real call to the backend - path_add_device or udev_assign_seat.
Also, failure to initialize the quirks subsystem just means we continue as
normal. This shouldn't be a hard failure, it just means a lot of devices won't
work properly.
If the LIBINPUT_DATA_DIR environment variable is set, that directory is used
for the data file. Only that directory, no custom override file in that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't want any of the test devices to match the local machine's DMI
modalias. This was a major drawback in the previous test suite, hacking the
dmi modalias string was nontrivial but a wrong string could cause false
positives or negatives.
The quirks system is internal, so rather than having some fancy API we just
hook it off the environment variable that the test suite always sets. Hacky,
but a lot easier than the other options.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we had all extra device information ("This is an Apple Touchpad",
"This touchpad causes pointer jumps", etc.) in the udev hwdb. The problem with
the hwdb is that updating it is nontrivial for the average user and debugging
when things go wrong is even harder. Plus, the hwdb has a matching scheme that
is unpredictable unless one is familiar with the implementation.
This patch set moves the hwdb entries into .ini style text files, with a
simple line-based parser. A new libinput list-quirks tool can list the quirks
applied to any given device, in --verbose mode it prints all matches as they
apply or not apply.
The data files are currently unused by libinput, that comes in a later patch.
They're installed though, the defaults point to the /usr/share/libinput
directory and for *temporary* local overrides the single file
/etc/libinput/local-overrides.quirks.
Failure to parse any file is a hard failure for the quirks system, but if the
local override file doesn't exist that's fine.
THIS IS NOT A CONFIGURATION INTERFACE! None of these settings are exposed via
the libinput_device_config_* calls. There is no API guarantee for these files,
think of them as source code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The lenovo compact keyboard with trackpoint has a sensitivity of 5, which
causes the trackpoint range to be 0. This in turn causes inf/NaN during
pointer acceleration as we divide by 0 and makes the cursor go unpredictably
somewhere it probably shouldn't be.
This is part of a wider problem in that the current sensitivity handling
doesn't work well for values well below the default of 128. Any such values
are scaled up to multiples of pixels instead of just working as-is.
Reverting the automatic sensitivity parsing, any systemd udev property set to
change the sensitivity increases it, so we don't run into this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1583324
This reverts commit a4036a33ca.
LIBINPUT_ATTR_THUMB_PRESSURE_THRESHOLD now determines whether we do thumb
pressure detection or not. Much better than having a hardcoded default that
may or may not be correct on any given device.
This patch is likely to break thumb detection on some touchpads, the only
property so far is to restore the default of 100 for all Lenovo Thinkpad
touchpads. More rules are needed, we'll just wait until someone shouts.
https://bugs.freedesktop.org/show_bug.cgi?id=106458
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes the artificial 3 keyboard limit. If you have more internal
keyboards than that, something is wrong in your setup but that shouldn't stop
us from working. Or more specificially: this can happen easily when running
tests so let's not fail the test suite because we created a few hundred
keyboards.
We'll still throw out a log message though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes the artificial 3 keyboard limit. If you have more internal
keyboards than that, something is wrong in your setup but that shouldn't stop
us from working. Or more specificially: this can happen easily when running
tests so let's not fail the test suite because we created a few hundred
keyboards.
We'll still throw out a log message though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This raises the trackpoint speed limit to something more conducive to
long-distance moves.
https://bugs.freedesktop.org/show_bug.cgi?id=106506
Signed-off-by: Chow Loong Jin <hyperair@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This seems to give me roughly the same behaviour as macos does on the default
0 speed setting.
* Default speed is lower than before by around 30% [1]
* Acceleration kicks in much sooner (130mm/s vs 250mm/s before)
* Acceleration kicks in slower at lower speeds, so the change from 130mm/s to
150mm/s is less than that of 320mm/s to 350mm/s
* The effect of the speed setting is a wide-range constant (de|ac)celeration
[2], which means:
* The unaccelerated baseline up until the threshold now changes with the
speed setting
* The threshold is now the same for all speeds
* The range of the speed setting should now easily cover all desired device
speeds.
* Acceleration is steeper at higher speeds
* Deceleration was left as-is.
[1] This may or may not fix the jumping pointer issues caused by the previous
high defaults. When you have high default acceleration you move the finger
slower. This slow movement caused some touchpads (mostly seen on Lenovos) to
create pointer jumps. These weren't seen on synaptics previously because of a
combination of higher user finger speed (thus not triggering the bug) or just
not being as obvious (2px jump vs 10 px jump).
[2] The speed setting is actually a curve, the closer you get to 1.0 the more
difference you see between two different values. The curve's points are:
-1/0, 0/1, 1/5, so the resolution is closer for slow speeds. We still have
double resolution on the setting though so you'll find what you want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.
Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.
This reverts commit d8bd650540.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are 4 possible cases why a touchpad suspends right now: lid switch,
tablet mode switch, sendevents disabled and sendevents disabled when an
external mouse is present.
But these reasons can stack up, e.g. a lid switch may happen while send events
is disabled, disabling one should not re-enable the touchpad. This patch adds
a bitmask to remember the reasons we're current suspended, resuming only
happens once all reasons are back to 0.
https://bugs.freedesktop.org/show_bug.cgi?id=106498
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because we register the handler separately (once for lid, once for
tablet-mode) the handler is called twice for the same event. This causes a
double-suspend of the touchpad, though it doesn't seem to have any real
effect.
Split it up so that each handler function only does one thing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And rename the model flag, no point in having separate flags here, we likely
have to add more devices over time.
https://bugs.freedesktop.org/show_bug.cgi?id=106534
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Well, I say "measure" but really at this point it just reads the
properties/axes and then does it's best to auto-generate a hwdb entry that
matches the user's hardware and sets a fuzz value on the device. Ideally this
reduces the number of hand-holding required in bugzillas. There are plenty of
things that can go wrong, so our fallback is still to throw up our hands and
point to the documentation.
https://bugs.freedesktop.org/show_bug.cgi?id=98839
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
