<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - One-finger tap registered as two-finger tap when touch-size-based palm rejection is triggered" href="https://bugs.freedesktop.org/show_bug.cgi?id=103210#c13">Comment # 13</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - One-finger tap registered as two-finger tap when touch-size-based palm rejection is triggered" href="https://bugs.freedesktop.org/show_bug.cgi?id=103210">bug 103210</a> from <a class="email" href="mailto:peteryuchuang@gmail.com" title="Peter Y. Chuang <peteryuchuang@gmail.com>"> Peter Y. Chuang</a> <pre>Created <a href="attachment.cgi?id=135279" name="attach_135279" title="libinput-debug-events: tapping failure after typing">attachment 135279</a> <a href="attachment.cgi?id=135279&action=edit" title="libinput-debug-events: tapping failure after typing">[details]</a> libinput-debug-events: tapping failure after typing (In reply to Peter Hutterer from <a href="show_bug.cgi?id=103210#c11">comment #11</a>) > (In reply to Peter Y. Chuang from <a href="show_bug.cgi?id=103210#c10">comment #10</a>) > > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>