Bug 105535 - SynPS/2 Synaptics TouchPad detects fingers not touching the touchpad while using two-finger scrolling
Summary: SynPS/2 Synaptics TouchPad detects fingers not touching the touchpad while us...
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 105258
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-16 00:20 UTC by Sergei Jakovlev
Modified: 2018-03-23 04:20 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Evemu recording of the issue. (294.33 KB, text/plain)
2018-03-17 00:30 UTC, Sergei Jakovlev
Details
evemu-descibe-ThinkPad-T430s (3.43 KB, text/plain)
2018-03-19 20:34 UTC, Matthias Baur
Details

Description Sergei Jakovlev 2018-03-16 00:20:59 UTC
Synaptics touchpad is way too sensitive when using libinput during two finger scrolling - it detects fingers not touching the touchpad at all (2-3 mm away from the surface). The behavior of the cursor itself when not scrolling seems OK (it does not move when a finger is not touching the surface). The speed of scrolling and cursor movement is also OK.

As per https://wayland.freedesktop.org/libinput/doc/latest/touchpad_pressure.html I tried to run "libinput measure touchpad-pressure", but it fails on my machine:

# libinput measure touchpad-pressure
Using SynPS/2 Synaptics TouchPad: /dev/input/event8

Error: device does not have ABS_MT_PRESSURE

I would like to ask for advice how to proceed. As far as I understand, there is no user configurable sensitivity in libinput, and normal recommendation is to use pressure measurement tool and file a bug report, but the tool fails on my machine.

Other information required by bug reporting guidelines:

$ pacman -Ss libinput
extra/libinput 1.10.3-1 [installed]
    Input device management and event handling library
extra/xf86-input-libinput 0.26.0-1 (xorg-drivers) [installed]
    Generic input driver for the X.Org server based on libinput

$ xinput list-props "SynPS/2 Synaptics TouchPad"
Device 'SynPS/2 Synaptics TouchPad':
	Device Enabled (140):	1
	Coordinate Transformation Matrix (142):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Tapping Enabled (275):	1
	libinput Tapping Enabled Default (276):	0
	libinput Tapping Drag Enabled (277):	1
	libinput Tapping Drag Enabled Default (278):	1
	libinput Tapping Drag Lock Enabled (279):	0
	libinput Tapping Drag Lock Enabled Default (280):	0
	libinput Tapping Button Mapping Enabled (281):	1, 0
	libinput Tapping Button Mapping Default (282):	1, 0
	libinput Natural Scrolling Enabled (283):	0
	libinput Natural Scrolling Enabled Default (284):	0
	libinput Left Handed Enabled (285):	0
	libinput Left Handed Enabled Default (286):	0
	libinput Accel Speed (287):	0.000000
	libinput Accel Speed Default (288):	0.000000
	libinput Scroll Methods Available (289):	1, 1, 0
	libinput Scroll Method En<code>abled (290):	1, 0, 0
	libinput Scroll Method Enabled Default (291):	1, 0, 0
	libinput Send Events Modes Available (260):	1, 1
	libinput Send Events Mode Enabled (261):	0, 0
	libinput Send Events Mode Enabled Default (262):	0, 0
	libinput Disable While Typing Enabled (292):	1
	libinput Disable While Typing Enabled Default (293):	1
	Device Node (263):	"/dev/input/event8"
	Device Product ID (264):	2, 7
	libinput Drag Lock Buttons (294):	<no items>
	libinput Horizontal Scroll Enabled (295):	1

Laptop: HP ProBook 4530s

$ cat /sys/class/dmi/id/modalias
dmi:bvnHewlett-Packard:bvr68SRRVer.F.63:bd04/06/2017:svnHewlett-Packard:pnHPProBook4530s:pvrA0000C02:rvnHewlett-Packard:rn167C:rvrKBCVersion22.26:cvnHewlett-Packard:ct10:cvr:
Comment 1 Oleksandr Popel 2018-03-16 21:24:35 UTC
I can confirm this bug. I've also found that it appeared in libinput-1.10 and does not exist in 1.9.

My hardware (Lenovo ThinkPad T420) also does not have ABS_MT_PRESSURE, so can't help with that, but I've recorded the bug with evemu (didn't touch touchpad while scrolling):
https://pastebin.com/rj6DJjpq

udevadm info:
https://pastebin.com/wXNVz7kK

/sys/class/dmi/id/modalias contents:
dmi:bvnLENOVO:bvr83ET79WW(1.49):bd09/05/2016:svnLENOVO:pn4236FJ1:pvrThinkPadT420:rvnLENOVO:rn4236FJ1:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
Comment 2 Sergei Jakovlev 2018-03-17 00:30:02 UTC
Created attachment 138162 [details]
Evemu recording of the issue.

Also made an evemu recording while also filming the touchpad. Please see the video on YouTube: https://youtu.be/fgoul6l-1_E - evemu is recording this specific interaction. Note the browser tab scrolling in the background.
Comment 3 Matthias Baur 2018-03-17 14:22:34 UTC
I can confirm this behaviour for a Lenovo T430s with libinput 1.10.x. Downgrading to libinput 1.9.4 "fixed" it.

I can also confirm that libinput measure touchpad-pressure/touch-size isn't working on this device.
Comment 4 Peter Hutterer 2018-03-19 03:12:09 UTC
Right, this means that this device doesn't use the same pressure threshold values that we use for other synaptics devices. The touch-size tool wouldn't apply here, only the touchpad-pressure tool but that expects per-touch pressure. It's a python script so I'd appreciate any help in adjusting it to work for single-touch ABS_PRESSURE. Without that tool, you're down to staring/grepping at ABS_PRESSURE values and picking something useful.

Commit 46af543b49b4e2d75348 is a good reference for how the final patch will look like, just with whatever numbers you come up with. Once you put those into the hwdb (see https://wayland.freedesktop.org/libinput/doc/latest/touchpad_pressure.html) you can build and test in-tree with sudo ./builddir/libinput-debug-events --verbose. That will show when a touch is detected based on pressure, and if you see POINTER_AXIS events or POINTER_MOTION events float past, those are real events that would move the pointer. Rinse-wash-repeat until you're happy, then restart X/Wayland to test with the real pointer.

Olexandr, Matthias: make sure you have the same device, specifically whether it's a INPUT_PROP_SEMI_MT device in evemu. And any patch would have to be DMI-specific so I'll need the evemu-record for all of them to adjust that anyway.

Last comment: do you see any bugs in normal single-finger pointer motion or does this exhibit the same issues? Because otherwise we may have other issues, specifically that the pressure is garbage once two fingers are applied and that requires other fixes...
Comment 5 Oleksandr Popel 2018-03-19 12:35:20 UTC
I'll try to play with pressure threshold values later. As for single-finger pointer motion - it's normal. Bug does not not appear there. Also, it does not appear without normal touching first. As seen in video by Sergei, first you have to actually touch a touchpad and only then you can scroll without touching it. So there's that.
And what about the fact that bug didn't exist in 1.9? What changes was made that could provoke it?
Comment 6 Matthias Baur 2018-03-19 20:34:07 UTC
Created attachment 138207 [details]
evemu-descibe-ThinkPad-T430s

evemu describe of my ThinkPad T430s. As far as I can tell, it looks pretty much the same as the one Sergei posted.
Comment 7 Matthias Baur 2018-03-19 20:46:16 UTC
Thanks, I've patched the measurement tool as following:

diff --git a/tools/libinput-measure-touchpad-pressure b/tools/libinput-measure-touchpad-pressure
index 89dd117f..7ea44bee 100755
--- a/tools/libinput-measure-touchpad-pressure
+++ b/tools/libinput-measure-touchpad-pressure
@@ -155,7 +155,7 @@ class Device(object):
         # then extract the pressure absinfo from that
         all_caps = self.device.capabilities(absinfo=True)
         caps = all_caps.get(evdev.ecodes.EV_ABS, [])
-        p = [cap[1] for cap in caps if cap[0] == evdev.ecodes.ABS_MT_PRESSURE]
+        p = [cap[1] for cap in caps if cap[0] in [evdev.ecodes.ABS_MT_PRESSURE, evdev.ecodes.ABS_PRESSURE] ]
         if not p:
             raise InvalidDeviceError("device does not have ABS_MT_PRESSURE")
 
@@ -226,6 +226,10 @@ def handle_abs(device, event):
         s = device.current_sequence()
         s.append(Touch(pressure=event.value))
         print("\r{}".format(s), end="")
+    elif event.code == evdev.ecodes.ABS_PRESSURE:
+        s = device.current_sequence()
+        s.append(Touch(pressure=event.value))
+        print("\r{}".format(s), end="")
 
 
 def handle_event(device, event):


Seems to work now :) I'm currently experimenting with it, but think 32:25 should be a good value to start with.

What I found kind of strange are the hwdb default values:

s0me0ne@s0me0ne-Thinkpad:~/Sources/libinput$ sudo ./tools/libinput-measure-touchpad-pressure
Using SynPS/2 Synaptics TouchPad: /dev/input/event15

Ready for recording data.
Pressure range used: 25:30
Palm pressure range used: 130
Place a single finger on the touchpad to measure pressure values.
Ctrl+C to exit
^C

The man page of libinput-measure-touchpad-pressure says "The thresholds have to be in device-specific pressure values and it is required that down >= up.". "down >= up." seems to be not fulfilled.
Comment 8 Peter Hutterer 2018-03-20 05:44:15 UTC
oops, the range mismatch is fixed in master now (4ff5f02d9c). But the big thing here is:

> As for single-finger pointer motion - it's normal. Bug does not not appear there.

Basically this means that the touchpad pressure changes when two fingers are down. That's not good... Anyway, I bisected this and came up with: commit 3979b9e16a5ed141506d95f80ddfd7b94651dcfa. Basically the problem is that we now assume that when we have more fingers down than the touchpad can individually detect (>1 for semi-mt devices) then we assume all fingers have an above-threshold pressure value.

This matches the data in the evemu recording, the pressure is well below the thresholds yet we treat it as down. Should be fixable.
Comment 10 Peter Hutterer 2018-03-23 04:20:13 UTC
commit 3f5ff113a8c9469b084941b3b3157d7da95600d1
Author: Peter Hutterer <>
Date:   Wed Mar 21 10:24:12 2018 +1000

     touchpad: only keep low-pressure fingers alive for 2+-slot 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.