sorry, that recording doesn't start from a neutral touchpad state, I can't replay this here. Can you re-record please, starting with no fingers on the touchpad? Thanks

Created attachment 134858 [details]
evemu-record of the event (v2)

I have included a few more taps in the recording, as I find that often times the first tap after the palm is rested on the touchpad is ignored altogether.

Created attachment 134859 [details]
evemu-record for a rejected palm and two-finger taps

This is the recording for two-finger taps when a palm is rested on the touchpad FYI. Here, the taps are registered as three-finger taps instead. Again, sometimes the taps are ignored altogether.

thanks, reproduced it with attachment 134859 [details]. The basic problem is simple, the touchpad tap machine doesn't handle palms (based on the assumption that you won't tap with a palm on the touchpad) so palm touches are detected as normal fingers - unless they're detected as thumb first (which may be why you're getting inconsistent behaviour).

not an easy fix though, this needs to be fully worked into the (already quite complicated) touchpad tap state machine. unlike thumb, the palm detection can trigger at any time so we need to make sure we get out of the state machine in a defined way at every point.

https://lists.freedesktop.org/archives/wayland-devel/2017-November/035699.html

Thanks. I'm testing the patch at the moment. It works pretty well on most occasions. Though there are occasions where the taps seem to be ignored completely, and at the moment I suspect it's related to disable-while-typing.

Here are the steps that triggers the misbehaviour:

1. Type something on the keyboard with the palm(s) on the touchpad
2. Stop typing, with one palm remaining on the touchpad
3. (This step optional) Move the cursor
4. Now the touchpad isn't reponsive to taps.
5. After lifting the palm, the touchpad doesn't respond to the first tap.


The same misbehaviour can also be reproduced with the following steps:

1. Type something *without* the palm or anything touching the touchpad
2. Stop typing, but immediately put a palm on the touchpad
3. Now the touchpad isn't reponsive to taps.

I also notice that when the taps are ignored under such condition, the cursor moves on every tap. As far as I can tell, cursor doesn't move in normal tapping.

yep, the first case was a bug when recovering from idle, good find, thanks.
try the last commit on:
https://github.com/whot/libinput/tree/wip/touchpad-tap-palm-detect

I can't seem to reproduce the second issue though, typing, palm down + tap
always triggers a tap here.

For some reason, after adding the new commit to my build, gnome-shell crashes quite often. Looking through the logs, I find these:

org.gnome.Shell.desktop[1034]: gnome-shell: ../libinput/src/evdev-mt-touchpad-tap.c:1000: tp_tap_handle_state: Assertion `tp->tap.nfingers_down > 0' failed.
systemd-coredump[2119]: Process 1034 (gnome-shell) of user 1000 dumped core.
                                                #1  0x000055fab182c562 n/a (gnome-shell)
                                                #17 0x000055fab182c011 n/a (gnome-shell)
                                                #19 0x000055fab182c16a n/a (gnome-shell)

Since it crashes too often, I haven't been able to test the last commit for long enough, nor have I been able to figure out what triggers the crash.

best to revert to the previous version, then build (but not install) the tree and run libinput-debug-events directly from the build directory. That should make it possible to reproduce the crash and find the issue. Unfortunately the test suite didn't trigger it, so it's something we'll need a new test for.

Now I have at last tested it for more than a few minutes without a crash, these are what I've found:

1. Sometimes it does work as expected. Tap-to-click works after typing with palm on the touchpad, and then with the palm staying on the touchpad.

2. More of the times it doesn't work. In fact, taps don't work even well after typing has ended *and* the palm is lifted. In this scenario, tap-to-click doesn't recover until I type for a bit with my palm *off*. After that, it works again after a tap or two, I think.

Regarding the typing-with-palm-off-then-palm-on scenario, I think it depends on how quickly you put your palm on the touchpad after finishing typing. I'd say tapping works if I put my palm on the touchpad about a second after the typing has ended. But if the palm is put on the touchpad *immediately* after the last keystroke, then tapping doesn't work.

(In reply to Peter Y. Chuang from comment #10)
> 2. More of the times it doesn't work. In fact, taps don't work even well
> after typing has ended *and* the palm is lifted. In this scenario,
> tap-to-click doesn't recover until I type for a bit with my palm *off*.
> After that, it works again after a tap or two, I think.

I really need something reproducible here or some pattern that we suspect. It's a bit tricky to write test cases otherwise. I suspect you're hitting one state where we don't recover correctly, but I don't quite know which one it is yet.

> Regarding the typing-with-palm-off-then-palm-on scenario, I think it depends
> on how quickly you put your palm on the touchpad after finishing typing. I'd
> say tapping works if I put my palm on the touchpad about a second after the
> typing has ended. But if the palm is put on the touchpad *immediately* after
> the last keystroke, then tapping doesn't work.

There's a 500ms timeout (provided 2+ key presses) after the last key event. If you put your palm down within that timeout, it'll be detected as dwt palm. After those 500ms it'll be detected based on pressure/size/whatever. I definitely put my palm down within those 500ms, if you run libinput debug-events --verbose it'll print the type of palm detection triggered.

Ok, I have a reproducer for the crash in the form of a test case. Sequence of events is:
* key event - starts dwt timeout
* touch down
* dwt timeout expiry
* touch changes to palm based on pressure/size

Cause is, I think, the dwt code that disables and re-enables tap so we miss out on the TOUCH_BEGIN event while dwt is active and then crash when the assertion is it because we're one behind. I'll fix this asap.

Created attachment 135279 [details]
libinput-debug-events: tapping failure after typing

(In reply to Peter Hutterer from comment #11)
> (In reply to Peter Y. Chuang from comment #10)
> > 2. More of the times it doesn't work. In fact, taps don't work even well
> > after typing has ended *and* the palm is lifted. In this scenario,
> > tap-to-click doesn't recover until I type for a bit with my palm *off*.
> > After that, it works again after a tap or two, I think.
> 
> I really need something reproducible here or some pattern that we suspect.
> It's a bit tricky to write test cases otherwise. I suspect you're hitting
> one state where we don't recover correctly, but I don't quite know which one
> it is yet.
> 

This is one of the ways to trigger the problem:

1. Type something with palm off the touchpad
2. *Immediately* after the last keystroke, tap the touchpad repeatedly
3. Taps thereafter are ignored
4. It is sometimes possible for tapping to recover after a few more taps, so perhaps dwt does time out correctly on some occasions. On some occasions though, it is only possible if you hit a few keys then wait a bit and start tapping again (see the attached log).

If I type with my palm(s) on the touchpad, taps are ignored almost all the time after typing ends, and the tap doesn't have to happen immediately following the last key stroke: I can stop typing and tap the touchpad a few seconds laster and still get no response. And whether the palm is lifted or not doesn't seem to matter. The only way to recover from it is to type something again with the palm off, then wait a bit and start tapping.

Although I have encountered a few times that the touchpad responds correctly after the last commit, the correct behaviour seems to happen only once throughout one session. For instance, it works out alright the first time after logging in (typing with palm on, then tapping after typing stops with one palm still on), but after that it reverts to the behaviour above.

> > Regarding the typing-with-palm-off-then-palm-on scenario, I think it depends
> > on how quickly you put your palm on the touchpad after finishing typing. I'd
> > say tapping works if I put my palm on the touchpad about a second after the
> > typing has ended. But if the palm is put on the touchpad *immediately* after
> > the last keystroke, then tapping doesn't work.
> 
> There's a 500ms timeout (provided 2+ key presses) after the last key event.
> If you put your palm down within that timeout, it'll be detected as dwt
> palm. After those 500ms it'll be detected based on pressure/size/whatever. I
> definitely put my palm down within those 500ms, if you run libinput
> debug-events --verbose it'll print the type of palm detection triggered.

That makes sense from the perspective of providing dwt, though it may make sense to recognise the tap in this scenario:

Typing with palm off -> Stop typing -> palm on within 500ms -> tap 1 second after the last keystroke

I'm not sure if this can affect dwt though.

With regard to the crash, my observation is that it may be related to dwt too, as you have discovered. One way to trigger it consistently is:

1. Type with palm off
2. *Immediately* put one palm on after stop typing

Another way is:

1. Type with one palm on
2. *Immediately* put another palm on after stop typing

The odd thing about the crash is that after a while without triggering any crash, the above methods can't trigger crashes any more. So it always happens in a fresh gnome-shell session, soon after logging in. This may be related to the observation above regarding the correct behaviour happening only once in a session.

The code lost track of the numbers of tapping fingers down which probably why sometimes it couldn't be triggered except on the first run. I've put more asserts in now to make sure that doesn't happen, and I fixed the tap suspend/resume issue that triggered the crash. same github url as above.

Tapping always seems to recover after dwt, albeit only after the 500ms timeout.

On that note: a separate bug would be (for your touchpad) to disable dwt by default. dwt is a kludge because we can't detect palms reliably enough but this shouldn't be the case on your touchpad. Might be worth turning it off and testing how well it behaves.

Thanks. I'm testing the newest patches, and I can confirm that it doesn't crash. More testing may be needed to confirm that everything works, but my early impression is that it behaves correctly in cases that used to cause problems yesterday.

With regard to dwt, I'm somewhat reluctant to turn that off outright, because, even with dwt on, there have been multiple instances where I accidentally moved the cursor or click/tap something, causing me to lose a large chunk of text. That being a real-world usage though means that it's somewhat difficult for me to pinpoint what has gone wrong. It could have been accidental taps between dwt timing-out and the next dwt initiation, or accidental click by the palm (as far as I can tell, touch-size-based palm rejection does a good job in rejecting palm movement and tap, but not if the palm presses on hard enough to trigger an actual click). I will file a separate bug if I can figure out what goes wrong there.

The dwt issue should be easier to identify once https://bugs.freedesktop.org/show_bug.cgi?id=103145 is fixed. Thanks for testing, I'll squash the branch together and send them to the list again.

hm... after having no noticeable problem for 3 days, I've just encountered a crash.

From journalctl, I see this:

org.gnome.Shell.desktop[1038]: gnome-shell: ../libinput/src/evdev-mt-touchpad-tap.c:1071: tp_tap_handle_state: Assertion `tp->tap.nfingers_down <= tp->nfingers_down' failed.

Then a few seconds afterwards, these:

systemd-coredump[7111]: Process 1115 (Xwayland) of user 1000 dumped core.
    
    Stack trace of thread 1115:
    #0  0x00007fa3e9c7d8a0 raise (libc.so.6)
    #1  0x00007fa3e9c7ef09 abort (libc.so.6)
    #2  0x0000559ea039cb9a OsAbort (Xwayland)
    #3  0x0000559ea03a26b3 n/a (Xwayland)
    #4  0x0000559ea03a34d5 FatalError (Xwayland)
    #5  0x0000559ea022ebaf n/a (Xwayland)
    #6  0x0000559ea039a711 n/a (Xwayland)
    #7  0x0000559ea03935bb WaitForSomething (Xwayland)
    #8  0x0000559ea035f3c3 n/a (Xwayland)
    #9  0x0000559ea0363660 n/a (Xwayland)
    #10 0x00007fa3e9c69f6a __libc_start_main (libc.so.6)
    #11 0x0000559ea022e20a _start (Xwayland)
    
    Stack trace of thread 1118:
    #0  0x00007fa3ea00e38d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007fa3e3734a64 n/a (swrast_dri.so)
    #2  0x00007fa3e37348b8 n/a (swrast_dri.so)
    #3  0x00007fa3ea00808a start_thread (libpthread.so.0)
    #4  0x00007fa3e9d3f47f __clone (libc.so.6)
    
    Stack trace of thread 1119:
    #0  0x00007fa3ea00e38d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007fa3e3734a64 n/a (swrast_dri.so)
    #2  0x00007fa3e37348b8 n/a (swrast_dri.so)
    #3  0x00007fa3ea00808a start_thread (libpthread.so.0)
    #4  0x00007fa3e9d3f47f __clone (libc.so.6)
    
    Stack trace of thread 1117:
    #0  0x00007fa3ea00e38d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007fa3e3734a64 n/a (swrast_dri.so)
    #2  0x00007fa3e37348b8 n/a (swrast_dri.so)
    #3  0x00007fa3ea00808a start_thread (libpthread.so.0)
    #4  0x00007fa3e9d3f47f __clone (libc.so.6)
    
    Stack trace of thread 1116:
    #0  0x00007fa3ea00e38d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007fa3e3734a64 n/a (swrast_dri.so)
    #2  0x00007fa3e37348b8 n/a (swrast_dri.so)
    #3  0x00007fa3ea00808a start_thread (libpthread.so.0)
    #4  0x00007fa3e9d3f47f __clone (libc.so.6)

systemd-coredump[7088]: Process 1038 (gnome-shell) of user 1000 dumped core.
    
    Stack trace of thread 1038:
    #0  0x00007f5fc3eecc40 raise (libpthread.so.0)
    #1  0x0000563013380562 n/a (gnome-shell)
    #2  0x00007f5fc3eecda0 __restore_rt (libpthread.so.0)
    #3  0x00007f5fc3b578a0 raise (libc.so.6)
    #4  0x00007f5fc3b58f09 abort (libc.so.6)
    #5  0x00007f5fc3b500dc __assert_fail_base (libc.so.6)
    #6  0x00007f5fc3b50153 __assert_fail (libc.so.6)
    #7  0x00007f5fb9e4aabf n/a (libinput.so.10)
    #8  0x00007f5fb9e45f39 n/a (libinput.so.10)
    #9  0x00007f5fb9e47e90 n/a (libinput.so.10)
    #10 0x00007f5fb9e3d84a n/a (libinput.so.10)
    #11 0x00007f5fb9e397cf libinput_dispatch (libinput.so.10)
    #12 0x00007f5fc1a6b05d n/a (libmutter-clutter-1.so)
    #13 0x00007f5fc2e23270 g_main_context_dispatch (libglib-2.0.so.0)
    #14 0x00007f5fc2e24f69 n/a (libglib-2.0.so.0)
    #15 0x00007f5fc2e25f42 g_main_loop_run (libglib-2.0.so.0)
    #16 0x00007f5fc130d030 meta_run (libmutter-1.so.0)
    #17 0x0000563013380011 n/a (gnome-shell)
    #18 0x00007f5fc3b43f6a __libc_start_main (libc.so.6)
    #19 0x000056301338016a n/a (gnome-shell)
    
    Stack trace of thread 1135:
    #0  0x00007f5fc3ee838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007f5fbadf7465 n/a (libmozjs-52.so.0)
    #2  0x00007f5fbadf76b5 n/a (libmozjs-52.so.0)
    #3  0x00007f5fbb1f52e5 n/a (libmozjs-52.so.0)
    #4  0x00007f5fbb215ca2 n/a (libmozjs-52.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 1041:
    #0  0x00007f5fc3c0ef7b __poll (libc.so.6)
    #1  0x00007f5fc2e24ed3 n/a (libglib-2.0.so.0)
    #2  0x00007f5fc2e25f42 g_main_loop_run (libglib-2.0.so.0)
    #3  0x00007f5fc3390208 n/a (libgio-2.0.so.0)
    #4  0x00007f5fc2e191eb n/a (libglib-2.0.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 1043:
    #0  0x00007f5fc3c0ef7b __poll (libc.so.6)
    #1  0x00007f5fc2e24ed3 n/a (libglib-2.0.so.0)
    #2  0x00007f5fc2e24fae g_main_context_iteration (libglib-2.0.so.0)
    #3  0x00007f5fac201b0e n/a (libdconfsettings.so)
    #4  0x00007f5fc2e191eb n/a (libglib-2.0.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)

    Stack trace of thread 1136:
    #0  0x00007f5fc3ee838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007f5fbadf7465 n/a (libmozjs-52.so.0)
    #2  0x00007f5fbadf76b5 n/a (libmozjs-52.so.0)
    #3  0x00007f5fbb1f52e5 n/a (libmozjs-52.so.0)
    #4  0x00007f5fbb215ca2 n/a (libmozjs-52.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 1040:
    #0  0x00007f5fc3c0ef7b __poll (libc.so.6)
    #1  0x00007f5fc2e24ed3 n/a (libglib-2.0.so.0)
    #2  0x00007f5fc2e24fae g_main_context_iteration (libglib-2.0.so.0)
    #3  0x00007f5fc2e25002 n/a (libglib-2.0.so.0)
    #4  0x00007f5fc2e191eb n/a (libglib-2.0.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 1137:
    #0  0x00007f5fc3ee838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007f5fbadf7465 n/a (libmozjs-52.so.0)
    #2  0x00007f5fbadf76b5 n/a (libmozjs-52.so.0)
    #3  0x00007f5fbb1f52e5 n/a (libmozjs-52.so.0)
    #4  0x00007f5fbb215ca2 n/a (libmozjs-52.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 1141:
    #0  0x00007f5fc3ee838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007f5fbadf7465 n/a (libmozjs-52.so.0)
    #2  0x00007f5fbadf76b5 n/a (libmozjs-52.so.0)
    #3  0x00007f5fbb1f52e5 n/a (libmozjs-52.so.0)
    #4  0x00007f5fbb215ca2 n/a (libmozjs-52.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 7085:
    #0  0x00007f5fc3c13e79 syscall (libc.so.6)
    #1  0x00007f5fc2e4cf2f g_cond_wait_until (libglib-2.0.so.0)
    #2  0x00007f5fc2e3f393 n/a (libglib-2.0.so.0)
    #3  0x00007f5fc2e3f55e g_async_queue_timeout_pop (libglib-2.0.so.0)
    #4  0x00007f5fc2e14041 n/a (libglib-2.0.so.0)
    #5  0x00007f5fc2e191eb n/a (libglib-2.0.so.0)
    #6  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #7  0x00007f5fc3c1947f __clone (libc.so.6)

    Stack trace of thread 1139:
    #0  0x00007f5fc3ee838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007f5fbadf7465 n/a (libmozjs-52.so.0)
    #2  0x00007f5fbadf76b5 n/a (libmozjs-52.so.0)
    #3  0x00007f5fbb1f52e5 n/a (libmozjs-52.so.0)
    #4  0x00007f5fbb215ca2 n/a (libmozjs-52.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 1140:
    #0  0x00007f5fc3ee838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007f5fbadf7465 n/a (libmozjs-52.so.0)
    #2  0x00007f5fbadf76b5 n/a (libmozjs-52.so.0)
    #3  0x00007f5fbb1f52e5 n/a (libmozjs-52.so.0)
    #4  0x00007f5fbb215ca2 n/a (libmozjs-52.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 1142:
    #0  0x00007f5fc3ee838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007f5fbadf7465 n/a (libmozjs-52.so.0)
    #2  0x00007f5fbadf76b5 n/a (libmozjs-52.so.0)
    #3  0x00007f5fbb1f52e5 n/a (libmozjs-52.so.0)
    #4  0x00007f5fbb215ca2 n/a (libmozjs-52.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 1131:
    #0  0x00007f5fc3c0ef7b __poll (libc.so.6)
    #1  0x00007f5f9bbda773 n/a (libpulse.so.0)
    #2  0x00007f5f9bbcbbd0 pa_mainloop_poll (libpulse.so.0)
    #3  0x00007f5f9bbcc271 pa_mainloop_iterate (libpulse.so.0)
    #4  0x00007f5f9bbcc301 pa_mainloop_run (libpulse.so.0)
    #5  0x00007f5f9bbda6ae n/a (libpulse.so.0)
    #6  0x00007f5f9b97981c n/a (libpulsecommon-11.1.so)
    #7  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #8  0x00007f5fc3c1947f __clone (libc.so.6)
    
    Stack trace of thread 1138:
    #0  0x00007f5fc3ee838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
    #1  0x00007f5fbadf7465 n/a (libmozjs-52.so.0)
    #2  0x00007f5fbadf76b5 n/a (libmozjs-52.so.0)
    #3  0x00007f5fbb1f52e5 n/a (libmozjs-52.so.0)
    #4  0x00007f5fbb215ca2 n/a (libmozjs-52.so.0)
    #5  0x00007f5fc3ee208a start_thread (libpthread.so.0)
    #6  0x00007f5fc3c1947f __clone (libc.so.6)

I'm not sure what the exact trigger was, as I was simply browsing the web and wasn't paying attention...

Created attachment 135424 [details]
evemu-records right before a crash triggered by touching the lower edge of the touchpad

I think I know how the problem is triggered. Apparently it happens after touching the lower edge of the touchpad. It could be a palm touching and moving along the lower edge by accident, or a single finger touching or moving along the edge, so it's probably related to thumb detection (?). I guess because I rarely have my thumb down on the lower edge of my touchpad (or anywhere on my touchpad really), the problem escapes detection for 3 days...

yep, it's a thumb detection bug. Should be fixed now on that branch with 58bee17f, thanks

Thanks. I've tested it for a bit, and so far I haven't encountered any crashes.

Though I've noticed that thumb rejection has the same behaviour as touch-size-based palm rejection prior to the patches here, in that when I touch the lower edge of the touchpad, tapping with one finger elsewhere on the touchpad sometimes behaves as though it were two-finger tapping (and two-finger tapping as three-finger tapping, etc). I'm not sure what the correct behaviour here should be, and since I don't normally put my thumb down in that area of the touchpad, this behaviour doesn't bother me all that much in normal use.

This may be a problem for a separate bug report. Let me know if you want me to file one.

Yes please. I noticed today when looking at the state diagram that thumb handling is a bit sporadic, so this definitely warrants another bug.

commit 46eab97538af18381243f5337bf3d29e4b21098f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Nov 3 10:59:36 2017 +1000

    touchpad: work palm detection into the tap state machine


That's the bit without the thumb detection, we'll handle that in bug 103809