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.

Created attachment 1057306 [details]
evemu-record of a single scroll

The physical dimensions of the pad are 76x45mm

Is the threshold distance configurable?

(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.

(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

(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)

can you give this one a try please?
http://koji.fedoraproject.org/koji/taskinfo?taskID=11753386

(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.

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?

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.

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

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.

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.

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!

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.