Bug 100122 - Touchpad too "sticky"
Summary: Touchpad too "sticky"
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 100413
  Show dependency treegraph
 
Reported: 2017-03-08 20:10 UTC by Paviluf
Modified: 2017-03-29 04:36 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
evemu record (348.54 KB, text/plain)
2017-03-08 21:33 UTC, Paviluf
Details
long evemu record (14.43 MB, application/zip)
2017-03-09 17:34 UTC, Paviluf
Details
short evemu record (150.19 KB, application/zip)
2017-03-10 04:48 UTC, Paviluf
Details
0001-touchpad-add-pressure-ranges-for-cyapa-touchpads.patch (973 bytes, patch)
2017-03-12 23:31 UTC, Peter Hutterer
Details | Splinter Review

Description Paviluf 2017-03-08 20:10:46 UTC
Hello,

My Cyapa touchpad is, for a lack of a better word, too "sticky". I mean that when I just move the cursor sometime it's like I had clicked and moved. That lead to unwanted selection, or moving, of elements.

HP Chromebook 14 (Falco), Fedora 25, libinput 1.6.2-2 - tap to click enabled

I think it was better on Fedora 24 but not 100% sure.

If some infos or tests are needed, I will be happy to provide them.

Thanks !
Comment 1 Peter Hutterer 2017-03-08 20:54:10 UTC
I'll need an (ideally short) evemu recording of one of those sequences where it goes wrong. Could be a stuck button in the higher levels, but that's what the recording should tell us.
Comment 2 Paviluf 2017-03-08 21:33:39 UTC
Created attachment 130134 [details]
evemu record

It happened near the end. I just moved the cursor and it's like I had left clicked and moved while keep clicked. That lead to unwanted selection of elements.
Comment 3 Peter Hutterer 2017-03-08 23:22:32 UTC
The problem is that the touchpad loses tracking, e.g. at timestamp 19.891130 you get a finger down but at 19.975974 the finger is released again. The total time is ca 80ms and well within the tap timeout threshold. The movement is within a few device units, so that threshold doesn't trigger either. And the next event comes ca 150ms after the release, so we can't even do a 'lookahead' to see if we have a busted event sequence. The same applies to the sequence at 20.648695.

Now, there is relatively little we can do but one thing I noticed is that the pressure defaults are different to what the touchpad sends. So what I'll need from you is a touchpad recording that's several hours long with a lot of interaction. That should give me enough information regarding pressure values for libinput 1.7 and with a bit of luck that may also fix some of this bug.
Comment 4 Paviluf 2017-03-09 17:34:57 UTC
Created attachment 130149 [details]
long evemu record

Here is a long evemu record
Thanks !
Comment 5 Peter Hutterer 2017-03-10 00:51:12 UTC
huh, I wonder if this is actually *too much* data. There's no clear cutoff like in other devices I've seen. This could mean that either the device doesn't have those cutoffs or that they just disappear in the noise. Please submit another recording with, say 10-20 touch sequences (just basic movements) max, thanks.
Comment 6 Paviluf 2017-03-10 04:48:02 UTC
Created attachment 130152 [details]
short evemu record

Here is a short one
Comment 7 Peter Hutterer 2017-03-12 23:31:02 UTC
Created attachment 130188 [details] [review]
0001-touchpad-add-pressure-ranges-for-cyapa-touchpads.patch

give this one a try please, thanks.
Comment 8 Paviluf 2017-03-13 21:39:06 UTC
I hope I used your patch correctly. Here is what I've done :

$> sudo dnf builddep libinput
$> git clone git://anongit.freedesktop.org/git/wayland/libinput
$> cd libinput
$> patch -p1 < patch
$> ./autogen.sh --prefix=/usr --libdir=/usr/lib64
$> make
$> sudo make install
$> sudo udevadm hwdb --update
$> sudo reboot

$> ls -l /usr/lib64/libinput.*

-rwxr-xr-x 1 root root     955 13 mars  19:03 /usr/lib64/libinput.la
lrwxrwxrwx 1 root root      19 13 mars  19:03 /usr/lib64/libinput.so -> libinput.so.10.12.1
lrwxrwxrwx 1 root root      19 13 mars  19:03 /usr/lib64/libinput.so.10 -> libinput.so.10.12.1
-rwxr-xr-x 1 root root  209136  9 mars  07:29 /usr/lib64/libinput.so.10.11.5
-rwxr-xr-x 1 root root 1080128 13 mars  19:03 /usr/lib64/libinput.so.10.12.1

If I did it right and it's not placebo effect, it seem better but the problem still occur at times.

Thanks !
Comment 9 Peter Hutterer 2017-03-13 21:57:22 UTC
yep, you did everything right. make sure that udevadm info /sys/class/input/eventX lists LIBINPUT_MODEL_CYAPA=1, otherwise it won't take effect. but this patch doesn't introduce any new hwdb stuff, so it should already be in place (i.e. if it was missing, it's a separate bug that we need to fix).

also, when you're on a git repository use git am instead of patch directly, it's much nicer. That's just nitpicking.

Play with the thresholds a bit and see if you can improve the behaviour. Maybe move it to 12/10 or 12/8 or so. fwiw, when you play around with this, try ./tools/event-debug first, then install and restart X/wayland. You don't need to run the udev bits or a reboot.

Note that this seems to be a general device issue here, so we can only *reduce* the number of cases this happens but not make it go away, see comment #3
Comment 10 Peter Hutterer 2017-03-15 23:31:16 UTC
ftr, the libinput 1.7 release is currently stalling on this, so please do try to give feedback soon, thanks.
Comment 11 Paviluf 2017-03-16 09:25:12 UTC
Oh I didn't know that ! I'm doing a lot of tests and the best settings for now is that :

tp->pressure.high = 8;
tp->pressure.low = 6;

I have to do more tests though :)
Comment 12 Peter Hutterer 2017-03-16 22:29:46 UTC
ok, thanks. I've updated this locally, please let me know by Monday if you
want any more changes. We can change it after the release if need be, but
being good enough is important ;)
Comment 13 Paviluf 2017-03-19 08:26:51 UTC
A friend with a Macbook make me realized this weekend that the problem is not exactly what I was thinking. At first I thought that the bug was just the left click and move like thing that I thought that shouldn't happen at all. In fact, and I'm not bad with computers, I wasn't aware at all of the feature "slow double tap and move" that act like a left click and move but when I saw my friend doing it on his Mac I understood that this was this feature that was unintentionally triggered by the real bug.

So after many tests I didn't manage to make the problem disappear and worst, now that I know the feature, I sometimes see me triggering it unintentionally (tap on something, release your finger and quickly touch again the touchpad to move).

It's a nice feature but as you can see it can be problematic and not well known. Maybe it should be disabled by default or at least we should be able to disable it.

Thanks !
Comment 14 Peter Hutterer 2017-03-19 22:12:53 UTC
oh, right, tap-and-drag. That would do it, yes. We do have a config option for this but (based on anecdata) most users of tapping want to be able to tap-and-drag. We have tapping disabled by default, but tap-and-drag enabled by default if tapping gets enabled. I'm quite hesitant to change that default but there is an option so you can disable it already. See the documentation as well, you may find it's a useful feature :)

http://wayland.freedesktop.org/libinput/doc/latest/tapping.html

I'll push the pressure thresholds as-is then.
Comment 15 Paviluf 2017-03-20 12:46:23 UTC
(In reply to Peter Hutterer from comment #14)
> We do have a config option for this

Thanks ! If I understand it's only possible to disable it with xorg.conf and not possible on wayland ?

> I'll push the pressure thresholds as-is then.

Do you mean that you don't change it compared to libinput 1.6 (I think you don't have to change it) ?
Comment 16 Peter Hutterer 2017-03-21 00:30:44 UTC
(In reply to Paviluf from comment #15)
> Thanks ! If I understand it's only possible to disable it with xorg.conf and
> not possible on wayland ?

depends on your compositor, GNOME doesn't have this option yet. Just found the bug here: https://bugzilla.gnome.org/show_bug.cgi?id=775755

> > I'll push the pressure thresholds as-is then.
> 
> Do you mean that you don't change it compared to libinput 1.6 (I think you
> don't have to change it) ?

I'll still change it to the one in Comment #11 because otherwise we'll likely miss touches. We can fine-tune later if it's really a problem.
Comment 17 Paviluf 2017-03-21 06:25:59 UTC
(In reply to Peter Hutterer from comment #16)
> depends on your compositor, GNOME doesn't have this option yet. Just found
> the bug here: https://bugzilla.gnome.org/show_bug.cgi?id=775755

Thanks

> I'll still change it to the one in Comment #11 because otherwise we'll
> likely miss touches. We can fine-tune later if it's really a problem.

Ok so use rather these values, it's the best I found.

tp->pressure.high = 10;
tp->pressure.low = 8;
Comment 18 Peter Hutterer 2017-03-22 00:49:29 UTC
> Ok so use rather these values, it's the best I found.
> 
> tp->pressure.high = 10;
> tp->pressure.low = 8;

done locally, thanks
Comment 19 Peter Hutterer 2017-03-22 22:22:30 UTC
commit 17e9dfd0d1aa82b76578efa8104eed80b25ff89c
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Mar 13 09:29:06 2017 +1000

    touchpad: add pressure ranges for cyapa touchpads


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.