Testing a 1.7.x pre-release build (from https://koji.fedoraproject.org/koji/taskinfo?taskID=18007385) of libinput I noticed a tendency for a drag across the touchpad to suddenly stop. Eventually I figured that it seemed to be pressure related - if I start on the left of the touchpad and drag right then there's a natural tendency if my hand is held still and the finger being dragged bends to make the move for pressure to reduce slightly as it gets further to the right until eventually the pressure is insufficient and the drag stops typically around 75% of the way across the screen. This was not noticeable in 1.6.x but I've been told that pressure sensitivity is a new addition which I guess would explain the issue.
same as bug 99976, I'll need an evemu record, but this time of a couple of touchpad interactions so I can look at the pressure values. Please make sure you don't have an accidental palm touch in the output or a light accidental finger touch.
Created attachment 129960 [details] evemu log
Created attachment 129961 [details] event log Here's the logs for this one. This time I started them both then did a single drag until it came to an abrupt halt. Then I lifted off and used Alt-Tab and Ctrl-C to stop them withouth any more touchpad interaction.
When you were using the synaptics driver, did you change its options for FingerHigh or FingerLow? here's what happens here, the touchpad is set up for a schmitt trigger with values 30 high and 25 low, i.e. over 30 triggers a touch down, falling below 25 triggers a touch up. In the recording this first happens here E: 5.600873 0003 0035 2390 # EV_ABS / ABS_MT_POSITION_X 2390 E: 5.600873 0003 003a 0024 # EV_ABS / ABS_MT_PRESSURE 24 E: 5.600873 0003 0000 2390 # EV_ABS / ABS_X 2390 E: 5.600873 0003 0018 0024 # EV_ABS / ABS_PRESSURE 24 E: 5.600873 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms and after that you don't make a pressure of 30 anymore. Device range is 0..3276, so 2390 is 73% of the way in, so that matches your description. The lowest pressure recording of true interaction seems to be 14. the synaptics driver pretty disabled pressure-based touchpads for elantech touchpads so that would explain why you're seeing a change now with libinput, I left it intentionally. I think measuring the real finger pressure would be a useful here, I'll see if I can produce a useful tool for this. You can hack this up for now if you want, in libinput's tp_init_pressure() function set tp->pressure.high and tp->pressure.low to 1. Then you can use the touchpad normally and run evemu-record in the background for a few hours to collect enough data.
Luckily I managed to find an old backup from when I was using the synaptics driver and yes, my X configuration had: Option "FingerHigh" "25" Option "FingerLow" "10" That's from some years ago so may not have been the final values but clearly I was setting them. So are you saying that those values are still set in the firmware somehow and affecting how it behaves?
Not quite. We get pressure values from the evdev node and until 1.7 we only relied on BTN_TOUCH for "touch is down". That's set by the kernel based on some pressure value (I need to check what the thresholds are for elantechs). in libinput 1.7 we now have a hi/lo schmitt trigger that defaults to iirc 30/25. Those defaults match the synaptics xorg driver but synaptics also has some model detection and effectively sets the hi/lo values to 1/1 in the case of elantech, i.e. disabling any pressure-based detection. I didn't take that bit for libinput because I wasn't sure it was (still) required and 1/1 exposes you to ghost touches on close finger hover. Based on your recording above it looks like you can easily get below 25, so this indicates the elantech thresholds need to be adjusted. Trivial to do, but I'd like to do so based on a bit of data :) Hence the need for an evemu recording of a few h of usage, I can run analysis scripts over that to guesstimate a good value range. It may end up to be 25/10, but let's analyse this first. Note that this is all in the xorg drivers/libinput, none of that is firmware or kernel (except for the BTN_TOUCH bit).
Created attachment 130038 [details] New evemu log Here's a new evemu log it covers a little under two hours of real time though probably only half of that is active use. If you need more then I can get it tomorrow...
Created attachment 130057 [details] Another, somewhat longer, log
ok, judging by those recordings, I'd say the range is 24/14 but for extra safety 24/10 may be prudent
git this one a try please: https://github.com/whot/libinput/tree/wip/touchpad-custom-pressure-values
Yes that seems to be much better and indeed I've now turned the speed setting back down to where it was before because the sluggish that I saw after the original update has gone away with the increased sensitivity.
https://lists.freedesktop.org/archives/wayland-devel/2017-March/033368.html
all done. will be in 1.7 and the next rc for it, thanks for the help. commit 957f8ec2f156f44cf08d7af8a2bebc7b114c2b90 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Mon Mar 6 14:31:40 2017 +1000 touchpad: add elantech-specific pressure values
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.