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 is supposed to come from systemd on a real setup, but for our test setup
we want to pass the test suite even when the system itself doesn't set it.
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>
Found by scan-build, running ptraccel-debug --mode=sequence --nevents=5
would use garbage custom_deltas.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes the dead code issue introduced in
822c97a1c2, print_accel was always
true so the rest of the code never got triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Coverity screwed up something so we can't submit builds right now, the
compilation units all fail. math.h pulls in a _Float128 type that coverity
cannot handle. So as a workaround, add an option to the build to avoid this
and remove it when the next version of coverity hopefully fixes this.
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>
We're printing most of those those as mm/s now, improve to use gnuplot for
loops, and a few other fixes. The low-dpi graph is still out of whack (or the
implementation is?), need to fix that separately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We pass the event to libinput_post_event() where it is appended to the event
queue. Except in these three cases clang doesn't seem to realize what's
happening and complains about memory leaks. I tried workarounds like
g_steal_pointer() but nothing I tried helps. So let's just pretend we're
freeing it when clang looks at us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is virtually the only one that matters at this point, the others may help
but they're usually more confusing than helpful.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When finger movement exceeded the motion threshold before the finger was
recognized as a thumb, it would never be regarded as a thumb by the tap system.
This prohibited tapping until the thumb was lifted.
This is fixed by moving the check for the thumb state up such that it
happens before the motion threshold check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This fixes a typo in the Chromebook R13 CB5-312T hwdb name match and
extends it to the full model name, so that potential future other
Chromebook R13 devices (that are not CB5-312T) won't use these quirks.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than going the roundabout way of having systemd set the sensitivity
followed by us reading that udev property and hoping, just take the
sensitivity directly from sysfs. This makes us basically independent of what
systemd does (or the lack of systemd, where that is a problem).
It does remove the chance of users to trick libinput by manually adjusting the
sensitivity after the udev rules kicked in, but seriously, we should work on
fixing acceleration properly in that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We fill in the events correctly and we already allowed the
get_transformed_x/y functions on a button event, there isn't really a reason
to prohibit these.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leftover from a previous version where printing and handling an event was
identical. Now we may handle events but not actually print them until a bit
later, so other events may have a (wrong) zero timestamp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not really an issue at this point, but some HID devices like sending
MSC_TIMESTAMP. Since we don't use them in libinput, all we do is drag
ourselves out of sleep, look at the event, frown because it's not our morning
coffee, and go back to sleep. Instead, disable the code altogether, libevdev
will mask it transparently and then the kernel will let us sleep.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The struct input_event is not y2038 safe.
Update the struct according to the kernel patch:
https://lkml.org/lkml/2018/1/6/324
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Too many touches are unreliable with 2+ fingers down and we should error on
the side of not detecting wobbling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we get an event other than a motion event we're not wobbling so we need to
reset and restart.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Otherwise we may detect wobble despite having a series of valid y movements,
e.g. the following sequence was detected as wobble:
x: 1 y: 0
x: 0 y: 1
x: 0 y: 2
x: 0 y: 2
x: 0 y: 1
x: -1 y: 0
x: 1 y: 0
Avoid this by resetting the history when we get a dx == 0 event. It'll take
longer for real wobble to be detected but it reduces the number of false
positives.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device frequently reports large pressure values during normal usage.
It does not require a tight palm threshold, because it is a desktop device
-- not built into a laptop surface -- so we can avoid false positives by
setting a very high threshold.
https://bugs.freedesktop.org/show_bug.cgi?id=105753
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it possible for callers to detect whether a touch device is
single or multitouch (or even check for things like dual-touch vs real
multi-touch) and adjust the interface accordingly.
Note that this is for touch devices only, not touchpads that are just pointer
devices.
https://bugs.freedesktop.org/show_bug.cgi?id=104867
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
