Bug 93947 - Palm detection misses
Summary: Palm detection misses
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
Depends on:
Reported: 2016-01-31 14:20 UTC by Cyril B.
Modified: 2017-05-10 03:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Palm detection misses (32.63 KB, text/plain)
2016-01-31 14:20 UTC, Cyril B.
debug events during replay (12.13 KB, text/plain)
2016-02-06 17:14 UTC, Cyril B.
record of the evemu-device during replay (32.63 KB, text/plain)
2016-02-08 11:19 UTC, Cyril B.
libinput-debug-events capture during replay of the real touchpad device (10.46 KB, text/plain)
2016-02-09 09:39 UTC, Cyril B.
libinput-debug-events capture during replay of the evemu device (12.13 KB, text/plain)
2016-02-09 09:42 UTC, Cyril B.
0001-touchpad-move-the-tapping-exclusion-zone-to-the-top-.patch (2.69 KB, patch)
2016-02-15 07:06 UTC, Peter Hutterer
Details | Splinter Review

Description Cyril B. 2016-01-31 14:20:18 UTC
Created attachment 121423 [details]
Palm detection misses

I've attached an evemu recording of palm detection misses. I was voluntarily resting my palm several times in a row to exhibit the issue, which happens frequently during normal use, for instance after my hands were off the keyboard for a while.

I'm using a Dell XPS 13 9350 with libinput 1.1.5 (with the disable tap-to-drag patch).
Comment 1 Peter Hutterer 2016-02-01 05:26:26 UTC
what's the effect you're seeing? I just replayed this on current master (d76dc643cd) and on a plain 1.1.5 and all touches are detected as palm.
Comment 2 Cyril B. 2016-02-01 18:25:51 UTC
Weird, I have just tested again with a plain 1.1.5 (without any patch), I still have the issue.

The effect is multiple clicks (7, if I count correctly). I'm under Xorg, with no special setting except for Accel Speed.
Comment 3 Peter Hutterer 2016-02-02 00:02:24 UTC
run libinput-debug-events --verbose --device /dev/input/eventX when you're replaying the recording and attach the output here please. the event node is either your touchpad, or the evemu event node.

Also, please try creating the device with evemu-device, then replaying and see if it happens with the recording, because that's what I'm using here.
Note that after evemu-device, run 
sudo libevdev-tweak-device --resolution=12,12 /dev/input/eventX for the newly created device, otherwise the resolution won't be set.

Plus the usual check just to make sure we're not looking at the wrong thing: are you using xf86-input-libinput?
Comment 4 Cyril B. 2016-02-06 17:14:01 UTC
Created attachment 121556 [details]
debug events during replay
Comment 5 Cyril B. 2016-02-06 17:15:10 UTC
I created a device with evemu-device, set libevdev-tweak-device on the new device, and played the recording: the cursor doesn't move.

I've attached the logs from libinput-debug-events while I'm replaying the recording on the (real) device.

And yes, I'm using xf86-input-libinput (0.16.0), as I'm using Xorg.
Comment 6 Peter Hutterer 2016-02-08 00:17:38 UTC
does the cursor move when you replay through your actual touchpad device? same command, you just pick the other event node. If not, any chance you can create a recording that reproduces the issue? Without that, I'm mostly stabbing in the dark here. The debug-events log shows that all touches are detected as palms.

Is there some other device that could interfere? Like a touch screen device that may send events unexpectedly?
Comment 7 Cyril B. 2016-02-08 09:19:44 UTC
Yes, the cursor does move when I replay with my actual device.

No other device that I can think of (I have no touch screen device):

$ xinput list                                                         
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=12   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Power Button                              id=8    [slave  keyboard (3)]
    ↳ Sleep Button                              id=9    [slave  keyboard (3)]
    ↳ Integrated_Webcam_HD                      id=10   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]
    ↳ Dell WMI hotkeys                          id=13   [slave  keyboard (3)]
Comment 8 Peter Hutterer 2016-02-08 10:48:48 UTC
That is weird(In reply to Cyril B. from comment #7)
> Yes, the cursor does move when I replay with my actual device.

that is weird. Please do the following: set up the evemu device with the original recording, then evemu-record that device when replaying. Attach the log here so we can diff the original and the emulated device, maybe that gives us some hint as to what's happening.
Comment 9 Cyril B. 2016-02-08 11:19:44 UTC
Created attachment 121585 [details]
record of the evemu-device during replay

Here is the record.
Comment 10 Peter Hutterer 2016-02-08 21:56:54 UTC
getting more ominous. diff shows no difference, a few events are slower by 1ms but that shouldn't make a difference, especially in this particular case where we don't depend on timers.

Run libinput-debug-events --verbose while you replay this through the real device and let's diff that.
Comment 11 Cyril B. 2016-02-09 09:39:53 UTC
Created attachment 121612 [details]
libinput-debug-events capture during replay of the real touchpad device
Comment 12 Cyril B. 2016-02-09 09:42:02 UTC
Created attachment 121613 [details]
libinput-debug-events capture during replay of the evemu device

Here are libinput-debug-events captures during replay of both the real device and the evemu device.
Comment 13 Peter Hutterer 2016-02-09 22:40:42 UTC
I don't get it, both of them show palm detection and neither of them show an event coming out of libinput. So afaict libinput is working correctly here.

Please triple-check your setup because if this is still moving the pointer, something else is going on here.
Comment 14 Cyril B. 2016-02-12 12:52:40 UTC
I triple-checked, and I finally found why I couldn't reproduce with the evemu-device: tapping wasn't enabled.

If I enable tapping (xinput set-prop 15 "libinput Tapping Enabled" 1) on the evemu-device, I can actually reproduce the clicks by replaying the recording.
Comment 15 Peter Hutterer 2016-02-15 07:04:27 UTC
Ah, ok. that makes sense now. Your touches fall into the lower area described here, which is why they're still detected as taps.
I think it makes sense to pull the exclusion zone down to the top edge of the software buttons. 

are you using software buttons or clickfinger?
Comment 16 Peter Hutterer 2016-02-15 07:06:54 UTC
Created attachment 121753 [details] [review]
Comment 17 Cyril B. 2016-02-15 08:42:15 UTC
I'm using clickfinger.
Comment 18 Peter Hutterer 2016-02-16 04:42:27 UTC
Give the patch in comment 16 a try please, let's see if that helps
Comment 19 Cyril B. 2016-02-16 12:16:54 UTC
I haven't been able to reproduce the misclicks by trying, so I guess it works properly. I'll let you know if real usage proves me wrong. Thanks again!

The pointer still does move when I start typing and my palm touches the touchpad, but it's much less problematic, at least in my case (I don't use focus-follows-mouse).

I'm curious though: does my touchpad not report pressure correctly, or is libinput not using it? When I'm moving my palm over the touchpad, the pointer moves normally, even though the pressure must be huge (so it's definitely not a finger).
Comment 20 Peter Hutterer 2016-02-16 22:12:30 UTC
We found pressure too unreliable for detecting palms. pressure on a touchpad isn't measured as a force but rather as a function of the surface area (as you press down, your finger flattens and gets bigger). That means that the pressure for a palm in the middle of the touchpad can be huge, but a palm at the edge of the touchpad, when half the palm is off the touchpad, can look like a normal finger. And many palm touches are a light touch only and are indistinguishable from a finger interaction.

All that assumes that the touchpad reports pressure. Your's doesn't, which makes it even harder :)
Comment 21 Cyril B. 2016-02-16 22:26:11 UTC
Thanks for the details. I haven't had any misclick today.

I wonder how OS X does palm detection, as it's extremely good: I can pretty much move my palm (or even both palms) on the whole touchpad in all directions/zones (even the middle), it still detects it's a palm and the pointer doesn't move. I guess they must use the pressure somehow, as I can't imagine how an algorithm would detect the palms otherwise.
Comment 22 Peter Hutterer 2016-02-16 22:29:40 UTC
Macs still have the best touchpad hardware. Also, they don't need to care about any other touchpad hardware, so low-maintenance across a multitude of different HW isn't much of an issue.
Comment 24 Peter Hutterer 2016-02-18 01:42:45 UTC
commit 79139ebcd1cc81eecdd2d0dc6f006fbec4c2c6f2
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Feb 15 17:02:45 2016 +1000

    touchpad: move the tapping exclusion zone to the top edge of the button

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.