Bug 1247958 - Noticeable delay before two-finger scrolling activates
Noticeable delay before two-finger scrolling activates
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libinput (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-07-29 06:48 EDT by Andrew Price
Modified: 2016-06-28 23:36 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-28 23:36:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
evemu-record of a single scroll (21.40 KB, text/plain)
2015-07-29 07:26 EDT, Andrew Price
no flags Details

  None (edit)
Description Andrew Price 2015-07-29 06:48:52 EDT
I recently fedup'd my Thinkpad (T510) to Fedora 22 and two-finger scrolling now doesn't kick in until I've dragged my fingers a noticeable distance, which feels quite uncomfortable. Previously, scrolling began as soon as I moved my fingers (or close enough that it wasn't noticeable). Is it possible to reduce or remove the delay?

$ xinput list-props 11
Device 'SynPS/2 Synaptics TouchPad':
	Device Enabled (139):	1
	Coordinate Transformation Matrix (141):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Tapping Enabled (274):	1
	libinput Tapping Enabled Default (275):	0
	libinput Accel Speed (276):	0.750000
	libinput Accel Speed Default (277):	0.000000
	libinput Natural Scrolling Enabled (278):	0
	libinput Natural Scrolling Enabled Default (279):	0
	libinput Send Events Modes Available (259):	1, 1
	libinput Send Events Mode Enabled (260):	0, 0
	libinput Send Events Mode Enabled Default (261):	0, 0
	libinput Left Handed Enabled (280):	0
	libinput Left Handed Enabled Default (281):	0
	libinput Scroll Methods Available (282):	1, 1, 0
	libinput Scroll Method Enabled (283):	1, 0, 0
	libinput Scroll Method Enabled Default (284):	1, 0, 0
	Device Node (262):	"/dev/input/event4"
	Device Product ID (263):	2, 7
Comment 1 Peter Hutterer 2015-07-29 06:55:44 EDT
the threshold distance should be 2mm, if it's more than that it's likely that something else is off. Please attach an evemu-record of a scroll sequence, together with the physical dimensions of your touchpad in mm. That should tell us more.
Comment 2 Andrew Price 2015-07-29 07:26:27 EDT
Created attachment 1057306 [details]
evemu-record of a single scroll

The physical dimensions of the pad are 76x45mm
Comment 3 Andrew Cook 2015-07-31 17:40:37 EDT
Is the threshold distance configurable?
Comment 4 Peter Hutterer 2015-08-03 22:16:47 EDT
(In reply to Andrew Price from comment #2)
> Created attachment 1057306 [details]
> evemu-record of a single scroll
> 
> The physical dimensions of the pad are 76x45mm

whoah, that's quite out of whack then. we'll need to get a udev override in for this, based on the coordinates your touchpad claims to be 59x33mm. Pls paste your /sys/class/dmi/id/modalias and the output of the touchpad-edge-detector (in libevdev-utils).


(In reply to Andrew Cook from comment #3)
> Is the threshold distance configurable?

no, no plans to make this configurable. Note that libinput will also detect a 2fg scroll when you leave the fingers in place for a while (500ms as of libinput 0.21.0) so small scroll movements will happen even when you don't trigger the threshold.
Comment 5 Andrew Price 2015-08-04 05:40:09 EDT
(In reply to Peter Hutterer from comment #4)
> (In reply to Andrew Price from comment #2)
> > Created attachment 1057306 [details]
> > evemu-record of a single scroll
> > 
> > The physical dimensions of the pad are 76x45mm
> 
> whoah, that's quite out of whack then. we'll need to get a udev override in
> for this, based on the coordinates your touchpad claims to be 59x33mm.

I didn't do a complete scroll from top to bottom to collect the coordinates, if that makes a difference.

> paste your /sys/class/dmi/id/modalias 

dmi:bvnLENOVO:bvr6MET81WW(1.41):bd10/26/2010:svnLENOVO:pn4384BR2:pvrThinkPadT510:rvnLENOVO:rn4384BR2:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:

> and the output of the
> touchpad-edge-detector (in libevdev-utils).

I ran it a bunch of times and there were some anomalies but this is the result that appeared most often:

Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event4
Move one finger around the touchpad to detect the actual edges
Kernel says:	x [1472..5888], y [1408..4820]
Touchpad sends:	x [778..6239], y [841..5330] |^C
Comment 6 Peter Hutterer 2015-08-05 02:20:18 EDT
(In reply to Andrew Price from comment #5)
> I didn't do a complete scroll from top to bottom to collect the coordinates,
> if that makes a difference.\

nope, doesn't matter, the range the device reports is always the same.

> > paste your /sys/class/dmi/id/modalias 
> 
> dmi:bvnLENOVO:bvr6MET81WW(1.41):bd10/26/2010:svnLENOVO:pn4384BR2:
> pvrThinkPadT510:rvnLENOVO:rn4384BR2:rvrNotAvailable:cvnLENOVO:ct10:
> cvrNotAvailable:
> 
> > and the output of the
> > touchpad-edge-detector (in libevdev-utils).
> 
> I ran it a bunch of times and there were some anomalies but this is the
> result that appeared most often:
> 
> Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event4
> Move one finger around the touchpad to detect the actual edges
> Kernel says:	x [1472..5888], y [1408..4820]
> Touchpad sends:	x [778..6239], y [841..5330] |^C

ok, thanks. I'll get this into systemd upstream so it's fixed for the future and figure out how to get this into fedora at the same time (f22 doesn't use systemd v220 which has all the bits to make this work, so bear with me pls)
Comment 7 Peter Hutterer 2015-11-09 01:42:59 EST
can you give this one a try please?
http://koji.fedoraproject.org/koji/taskinfo?taskID=11753386
Comment 8 Andrew Price 2015-11-09 14:37:59 EST
(In reply to Peter Hutterer from comment #7)
> can you give this one a try please?
> http://koji.fedoraproject.org/koji/taskinfo?taskID=11753386

I installed it and rebooted. I don't think it's made a difference, but it's difficult to tell as I've become accustomed to the delay. I probably would have noticed a change, I think. Would a new evemu-record log give a more objective answer?

That said, I'm still on Fedora 22 so I suspect the systemd 220 bits that you mentioned will not be there yet. The kernel still thinks the touchpad is the wrong size too. I do intend to upgrade to Fedora 23 in the next month or so.
Comment 9 Peter Hutterer 2015-11-09 16:21:50 EST
You can run this command manually to get the axis ranges into the right setting, but it's run-time only:

sudo libevdev-tweak-device --abs ABS_X --min 778 --max 6239 --res 72 /dev/input/eventX
sudo libevdev-tweak-device --abs ABS_Y --min 841 --max 5330 --res 100 /dev/input/eventX

where eventX is your event node. Then run the same two commands again with ABS_MT_POSITION_X and ABS_MT_POSITION_Y, respectively. When you run evemu-describe after that, you should see the axis ranges corrected to the settings you measured. And that should make the touchpad behave like it should :)
Can you give this a try please?
Comment 10 Andrew Price 2015-11-09 17:59:05 EST
There's something wrong with libevdev-tweak-device's option parsing:

$ sudo libevdev-tweak-device --abs ABS_X --min 778 --max 6239 --res 72 /dev/input/event4
libevdev-tweak-device: unrecognized option '--min'
libevdev-tweak-device: unrecognized option '--max'
libevdev-tweak-device: unrecognized option '--abs'

I took a look at the code (it could be less elaborate :) ) and figured that reordering the args might get around it. Although the getopt_long() in parse_options_mode() still printed some error messages, putting the --abs at the end made it change the values, and adding the ='s stopped it using "778" as the device path:

$ sudo libevdev-tweak-device --min=778 --max=6239 --res=72 --abs=ABS_X /dev/input/event4
libevdev-tweak-device: unrecognized option '--min=778'
libevdev-tweak-device: unrecognized option '--max=6239'

Anyway, I've run all 4 commands and confirmed that the values reported by evemu-describe have been changed. A similar delay is still noticeable but it hasn't gotten any worse.
Comment 11 Peter Hutterer 2015-11-09 20:17:28 EST
indeed, that's quite broken. I'll fix this, tahnks.

is the delay still of similar size? The resolution changed a bit from the original, so with the scratch build your fingers should not need to move more than 1mm before scrolling kicks in
Comment 12 Andrew Price 2015-11-09 21:14:43 EST
Having used it a bit more, the delay is hardly noticeable if I start scrolling after resting my fingers on the pad for a moment, but if my fingers are moving as I lower them, i.e. in a sweeping motion, the delay seems more noticeable. I'm not sure whether that's valuable information, but perhaps there's another delay factor coming from the initial touch recognition as opposed to the motion recognition, or something like that?

Thanks for all your help with this so far.
Comment 13 Peter Hutterer 2015-11-09 21:45:42 EST
we have a 500ms timeout, if you don't move past the threshold by then we always switch to two-finger scrolling so any movement counts as scroll event after that. this is intentional to make tiny scroll movements possible.
Comment 14 Andrew Price 2016-06-27 16:06:07 EDT
Hi Peter, I've recently updated to Fedora 24 and scrolling is nice and responsive now. I don't know what fixed it exactly but I'd be happy to see this bug closed. Thanks again!
Comment 15 Peter Hutterer 2016-06-28 23:36:54 EDT
we're heavily biasing towards 2fg scrolling now at the cost of (some) gesture detection. So depending on your finger position etc. the scrolling should trigger much earlier than it did before. Glad this works now, I'm closing this bug then.

Note You need to log in before you can comment on or make changes to this bug.