Bug 100122

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.

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.

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.

Created attachment 130149 [details]
long evemu record

Here is a long evemu record
Thanks !

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.

Created attachment 130152 [details]
short evemu record

Here is a short one

Created attachment 130188 [details] [review]
0001-touchpad-add-pressure-ranges-for-cyapa-touchpads.patch

give this one a try please, thanks.

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 !

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

ftr, the libinput 1.7 release is currently stalling on this, so please do try to give feedback soon, thanks.

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 :)

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 ;)

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 !

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.

(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) ?

(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.

(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;

> Ok so use rather these values, it's the best I found.
> 
> tp->pressure.high = 10;
> tp->pressure.low = 8;

done locally, thanks

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