With recent releases, there is now a long-ish delay before libinput reacts to two-finger scrolling (since it "need[s] to figure out whether it's a pinch or a scroll"). This doesn't disturb usage much, but filing a bug report for tracking purposes anyway, as asked. libinput 0.20.0 "ETPS/2 Elantech Touchpad"
The same thing happens on alps touchpad. I'll attach 2fg scroll evemu-recording.
Created attachment 117180 [details] 2fg scroll sequnece
http://lists.freedesktop.org/archives/wayland-devel/2015-July/023531.html
(In reply to Peter Hutterer from comment #3) > http://lists.freedesktop.org/archives/wayland-devel/2015-July/023531.html Hmm, it was only 3 mm? Sure seemed like at least a whole centimeter here, if not more. (Unless I'm misunderstanding how the threshold actually works. Or maybe I need a LIBINPUT_ATTR_SIZE_HINT for my touchpad?) Anyway, going to test the patch.
possibly, please attach an evemu recording, if the device doesn't have a ABS_X/Y resolution you need the size hint (or resolution hint)
Created attachment 117273 [details] evemu record of vertical scrolling (In reply to Peter Hutterer from comment #5) > possibly, please attach an evemu recording, if the device doesn't have a > ABS_X/Y resolution you need the size hint (or resolution hint) Attached. (Another reason I think I need to set these hints is because the regular pointer movement also became a bit slower after the remove-fake-resolution commits – makes me wish AccelSpeed went beyond 1.0. Just not sure how to find out the correct resolution.)
(In reply to Mantas Mikulėnas from comment #6) > (Another reason I think I need to set these hints is because the regular > pointer movement also became a bit slower after the remove-fake-resolution > commits – makes me wish AccelSpeed went beyond 1.0. Just not sure how to > find out the correct resolution.) (Actually nevermind that, 1.0 should be good enough until I figure out the resolution thing. But anyway I shouldn't be hijacking the thread.)
you get the resolution by dividing the x/y ranges 1280/704 by the width/height of the touchpad in mm. for elantech, that should be done with a13d936d741 though, check if that property appears on the udev device. (In reply to Mantas Mikulėnas from comment #6) > (Another reason I think I need to set these hints is because the regular > pointer movement also became a bit slower after the remove-fake-resolution > commits – makes me wish AccelSpeed went beyond 1.0. Just not sure how to > find out the correct resolution.) that's somewhat expected, before it was based on magic numbers, now it's based on physical properties. as long as the resolution is correct it should be closer to what other touchpads have. i'm surprised though that you want it faster, I find the normal touchpad speed quite fast already.
commit 3b73342e34196d355c07b89c109e8a91a9abf6ad Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Mon Jul 20 11:13:55 2015 +1000 touchpad: reduce 2fg scroll threshold to 2mm
(In reply to Peter Hutterer from comment #8) > you get the resolution by dividing the x/y ranges 1280/704 by the > width/height of the touchpad in mm. for elantech, that should be done with > a13d936d741 though, check if that property appears on the udev device. It does, but after actually measuring my touchpad (72x45), its resolution would be 17x17, not the 31x31 which was in that commit? After adding LIBINPUT_ATTR_RESOLUTION_HINT=17x17 to hwdb, it reacts to scrolling much faster now (though still seems at least 4-5 mm...) Hmm, the Windows driver came with a diagnostic tool, and I think I've seen resolution and other measurements in it. Going to check that.
(In reply to Mantas Mikulėnas from comment #10) > (In reply to Peter Hutterer from comment #8) > > you get the resolution by dividing the x/y ranges 1280/704 by the > > width/height of the touchpad in mm. for elantech, that should be done with > > a13d936d741 though, check if that property appears on the udev device. > > It does, but after actually measuring my touchpad (72x45), its resolution > would be 17x17, not the 31x31 which was in that commit? hmm, not good. we got those numbers from Elantech and were hoping we could rely on them... please post your /sys/class/dmi/id/modalias and I'll add this to the quirks. > After adding LIBINPUT_ATTR_RESOLUTION_HINT=17x17 to hwdb, it reacts to > scrolling much faster now (though still seems at least 4-5 mm...) that's true, your device is a semi-mt touchpad and the threshold on those is still 4mm. those devices have a lower resolution when two fingers are down, 2mm aren't enough to determine a direction, sorry. > Hmm, the Windows driver came with a diagnostic tool, and I think I've seen > resolution and other measurements in it. Going to check that. ah, cool. let us know what the results are please
(In reply to Peter Hutterer from comment #11) > (In reply to Mantas Mikulėnas from comment #10) > > (In reply to Peter Hutterer from comment #8) > > > you get the resolution by dividing the x/y ranges 1280/704 by the > > > width/height of the touchpad in mm. for elantech, that should be done with > > > a13d936d741 though, check if that property appears on the udev device. > > > > It does, but after actually measuring my touchpad (72x45), its resolution > > would be 17x17, not the 31x31 which was in that commit? > > hmm, not good. we got those numbers from Elantech and were hoping we could > rely on them... please post your /sys/class/dmi/id/modalias and I'll add > this to the quirks. dmi:bvnAmericanMegatrendsInc.:bvrK52JT.206:bd01/25/2011:svnASUSTeKComputerInc.:pnK52JT:pvr1.0:rvnASUSTeKComputerInc.:rnK52JT:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0: (It's really old, from 2011 or so, and is nearing its replacement date anyway.) However, if all Elantech touchpads really were 1280x704 @ 31x31, wouldn't they be _really small_ based on the same calculation? 41×23 mm seems tiny for modern laptops... > > After adding LIBINPUT_ATTR_RESOLUTION_HINT=17x17 to hwdb, it reacts to > > scrolling much faster now (though still seems at least 4-5 mm...) > > that's true, your device is a semi-mt touchpad and the threshold on those is > still 4mm. those devices have a lower resolution when two fingers are down, > 2mm aren't enough to determine a direction, sorry. Ah, alright then. (That also explains why both OSes had so much trouble recognizing three-finger taps...) Though, tbh, in this case I'd rather have only precise scrolling than gesture support, since it's used much more frequently than the latter. > > Hmm, the Windows driver came with a diagnostic tool, and I think I've seen > > resolution and other measurements in it. Going to check that. > > ah, cool. let us know what the results are please Nope, I was mistaken, it only showed "X,Y Max: 1280,704" (also finger positions, packet count, &c.) but not DPI nor physical size.
the touchpads have different ranges iirc, not all are 1280/704. And the newer generations fill in the resolution in the firmware, so all larger touchpads are likely covered. I hope, anyway.... (In reply to Mantas Mikulėnas from comment #12) > Though, tbh, in this case I'd rather have only precise scrolling than > gesture support, since it's used much more frequently than the latter. fair call, please file a separate bug for that though and we can track it that way. I can merge the DMI match into systemd if you want me to.
(In reply to Peter Hutterer from comment #13) > the touchpads have different ranges iirc, not all are 1280/704. And the > newer generations fill in the resolution in the firmware, so all larger > touchpads are likely covered. I hope, anyway.... Ah, right. > (In reply to Mantas Mikulėnas from comment #12) > > Though, tbh, in this case I'd rather have only precise scrolling than > > gesture support, since it's used much more frequently than the latter. > > fair call, please file a separate bug for that though and we can track it > that way. Alright, will do. > I can merge the DMI match into systemd if you want me to. It might be useful to others. (Note I actually got 17.7x15.6 from the 72x45mm measurement, only rounded it to 17x17 assuming it's the same in both directions. Not much of a difference.)
https://github.com/whot/systemd/commit/d0314dc45a5a75cec07bdab74676b3d9956381f6 this one should do the trick, any chance you can test it? I rounded up to 18/16
(In reply to Peter Hutterer from comment #15) > https://github.com/whot/systemd/commit/ > d0314dc45a5a75cec07bdab74676b3d9956381f6 > > this one should do the trick, any chance you can test it? I rounded up to > 18/16 Seems to work fine.
ok, thanks for testing. I'll get this upstream to systemd then and it'll eventually filter down to your distro.
merged into systemd: https://github.com/systemd/systemd/pull/783
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.