Created attachment 1058428 [details] Example of attempting to slowly scroll in Chrome Description of problem: Small two-finger scrolling movements do nothing. Past a threshold, it suddenly scrolls several lines at a time. This makes it hard to scroll by just one or two lines. Version-Release number of selected component (if applicable): libinput-0.20.0-3.fc22.x86_64 Tested on Wayland How reproducible: Every time Steps to Reproduce: 1. Use Elan Touchpad on Samsung Series 9 laptop 2. Open chrome on a long web page. Scroll down with two fingers, move them slowly. 3. Actual results: No scrolling, then scrolling is too fast Expected results: Gradual scrolling with acceleration depending on finger speed Additional info: evemu-record attached.
Also present on libinput-0.20.0-6, new evemu-record attached.
Created attachment 1058429 [details] As before, with libinput-0.20.0-6
resolution appears to be accurate enough, based on bug 1247257#c2 What I'm wondering though is: what do you consider a slow scroll? The first recording is roughly 9mm within 800ms. That's what I'd consider a fast scroll. There is a "dead zone" of 2mm for scrolling that we need to detect whether it's really a scroll event but you can work around this by leaving the fingers on the touchpad for 1 sec*. After that, any finger movement is interpreted as scroll and you can move as slow as you want. * that timeout should probably be a bit shorter
Moving 9mm within 800ms on the Synaptics driver will scroll 1-3 lines. A similar behaviour is seen on Windows. The same action on libinput scrolls many 10's of lines, after a deadzone of no scrolling. I think my term "slow scroll" is misleading, "small scroll" is more appropriate. I called it slow as I was reading the text on the page slowly; I wasn't trying to skim read the page and scroll quickly to the next section. I don't fully understand the recorded events file, it looks like it's only recording the touchpad input and not the emitted events. I'll describe the effect I see. 1. I want to scroll down one or two lines. I will want to do this regularly, so I expect it to take <1 second to perform the action. In this case, it took 800ms 2. I place two fingers on the touchpad 3. I make a small movement downwards, moving both fingers in parallel, at a constant velocity 4. I observe no movement for approximately 400ms, and approx half the distance travelled 5. Suddenly the screen starts scrolling many lines at a time, maybe 15 lines. I stop scrolling quickly as I can, once I register the movement. I would guess the 2mm deadzone is probably OK, but I would expect the next 8mm to scroll at most 4 lines at 2mm intervals. For larger movements, ie. travelling over 1cm in under 100ms, perhaps scrolling acceleration is desirable to allow users to scroll quickly through a large page.
(In reply to Richard Geary from comment #4) > Moving 9mm within 800ms on the Synaptics driver will scroll 1-3 lines. A > similar behaviour is seen on Windows. The same action on libinput scrolls > many 10's of lines, after a deadzone of no scrolling. I think my term "slow > scroll" is misleading, "small scroll" is more appropriate. I called it slow > as I was reading the text on the page slowly; I wasn't trying to skim read > the page and scroll quickly to the next section. > > I don't fully understand the recorded events file, it looks like it's only > recording the touchpad input and not the emitted events. yep, it records the events as they come out of the kernel. those are the same events libinput sees, so I can replay them here and get the same event sequence out of libinput. > 1. I want to scroll down one or two lines. I will want to do this > regularly, so I expect it to take <1 second to perform the action. In this > case, it took 800ms fwiw, libinput 0.21 reduced the timeout to 500ms > 2. I place two fingers on the touchpad > 3. I make a small movement downwards, moving both fingers in parallel, at a > constant velocity > 4. I observe no movement for approximately 400ms, and approx half the > distance travelled > 5. Suddenly the screen starts scrolling many lines at a time, maybe 15 > lines. I stop scrolling quickly as I can, once I register the movement. the jump is the weird thing here, this definitely shouldn't happen. when the threshold triggers, it should only take the last delta, not the threhold itself (so the first scroll event is only X, not 2mm+X). not sure yet why it happens for you though. > I would guess the 2mm deadzone is probably OK, but I would expect the next > 8mm to scroll at most 4 lines at 2mm intervals. For larger movements, ie. > travelling over 1cm in under 100ms, perhaps scrolling acceleration is > desirable to allow users to scroll quickly through a large page. do me a favour: can you reproduce this in firefox? I just installed chrome and I think I understand what you're referring to, but doing the same thing on firefox is a lot smoother and nicer. Can you confirm this? also, semi-related: please make sure you've got the latest gtk3 update installed for bug 1245247
Firefox does have smoother behaviour, but the sensitivity also feels broken. I've recorded some events. My gtk3+ is latest, v3.16.6-1. Observations : 1. Scrolling small distances (~10mm) slowly sometimes does nothing, until the 1s threshold is reached then the scrolling starts. 2. Scrolling one line with the two-finger scroll is feels very sensitive. This may be due to the timeout - tiny movements before the timeout do nothing, making it appear insensitive, then after 1s it suddenly starts to move. Perhaps a timeout is not a good idea, and the trigger should just be based on relative movement? 3. If you scroll ~10mm quickly, (eg. in 100ms) on the Synaptics driver, it appears to consistently emit 3 scroll events. On chrome, each scroll event appears to scroll ~3 lines. On firefox, it scrolls smoothly, but it scrolls the same distance (~12 lines). The same action on libinput (see two-finger-scroll-firefox-10mm.events) causes wildly varying amounts of scrolling, sometimes a few lines, sometimes scrolling a screen worth of content Question : Do you intend that pinching events are equally likely to be used as scrolling events? IMO I believe that scrolling is (and will be) a more common action, so it should be the pinching event that takes more time & precision to trigger.
Created attachment 1059127 [details] First attempt at scroll in firefox
Created attachment 1059128 [details] Scrolling 10mm, expecting ~12 lines of scroll
libinput-0.21.0-3.fc23 has been submitted as an update for Fedora 23. https://admin.fedoraproject.org/updates/libinput-0.21.0-3.fc23
libinput-0.21.0-3.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.21.0-3.fc22
(In reply to Richard Geary from comment #6) > Firefox does have smoother behaviour, but the sensitivity also feels broken. > I've recorded some events. My gtk3+ is latest, v3.16.6-1. > > Observations : > > 1. Scrolling small distances (~10mm) slowly sometimes does nothing, until > the 1s threshold is reached then the scrolling starts. I found a bug in the libinput code where a different threshold was overriding the new 2mm threshold, that's fixed in the update posted above. > 2. Scrolling one line with the two-finger scroll is feels very sensitive. > This may be due to the timeout - tiny movements before the timeout do > nothing, making it appear insensitive, then after 1s it suddenly starts to > move. Perhaps a timeout is not a good idea, and the trigger should just be > based on relative movement? no, we had that originally but it prevents really small scroll movements. right now, if you scroll slow enough there's a delay before it reacts, but then any movement will trigger. without that timeout, you'd always have to move but you don't know when it will respond, so overscrolling/underscrolling would happen all the time. This isn't much of an issue in a browser, but if you're using a CAD program where scroll==zoom this is very annoying. > 3. If you scroll ~10mm quickly, (eg. in 100ms) on the Synaptics driver, it > appears to consistently emit 3 scroll events. On chrome, each scroll event > appears to scroll ~3 lines. On firefox, it scrolls smoothly, but it scrolls > the same distance (~12 lines). > The same action on libinput (see two-finger-scroll-firefox-10mm.events) > causes wildly varying amounts of scrolling, sometimes a few lines, sometimes > scrolling a screen worth of content indeed, I can reproduce that, even with the above update. Not sure what is going on here yet but I'll take look. > Question : > Do you intend that pinching events are equally likely to be used as > scrolling events? IMO I believe that scrolling is (and will be) a more > common action, so it should be the pinching event that takes more time & > precision to trigger. we're already biased towards scrolling, especially with the last couple of patches. Right now, unless we really detect a pinch event, we won't trigger a pinch gestures. if you move both fingers in the same direction, if you rest your fingers before moving, all these trigger a scroll event. The only threshold we have still in place in libinput is the 2mm, but we'll need that one to figure out which direction the fingers are moving.
Please give this one a try: http://koji.fedoraproject.org/koji/taskinfo?taskID=10618095
ping?
libinput-0.21.0-3.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
libinput-0.21.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
libinput-0.99.1-1.fc23 has been submitted as an update to Fedora 23. https://bugzilla.redhat.com/show_bug.cgi?id=1249365
libinput-0.99.1-1.fc22 has been submitted as an update to Fedora 22. https://bugzilla.redhat.com/show_bug.cgi?id=1249365
libinput-0.99.1-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update libinput'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-13869
libinput-0.99.1-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update libinput'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-13868
Using libinput-0.99.1-1.fc22, the two-finger scrolling on my touchpad is now much better in Chrome and gedit, and reliable. But in Firefox it is completely unuseable as it is so insensitive. I can move my fingers down the entire touchpad and firefox will not scroll one line. It appears I have to wait ~1 second for any scrolling events to be detected, and regularly it will only scroll a few lines when I move across the entire touchpad. The distance between my fingers does not seem to matter. On seemingly random occasions, it scrolls many lines for the same movement.
weird. if it works in gedit/chrome I don't know why it wouldn't work in Firefox, especially since it works just fine here. is firefox the only app affected by this? do you see button 4/5 events in xev when you scroll?
libinput-0.99.1-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
libinput-1.0.0-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update libinput'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14280
Created attachment 1070155 [details] Small movement scrolling, sporadically detected Issue still present with libinput-1.0.0-1.bz1256045.1.fc22 Trying to scroll one or two lines with the two-finger scroll event. The same finger movement appears to be randomly detected as a multi-line scroll event, or ignored completely. This behavior feels inconsistent.
libinput-1.0.1-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update libinput'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14944
libinput-1.0.1-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15236
libinput-1.0.1-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update libinput'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15236
libinput-1.0.1-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Richard: the package is in stable now, can we consider this fixed or is it still an issue? Not sure with the last comment from you.
It is still an issue in F27. Touchpad is insensitive. I need a lot of pressure to activate the scrolling. Then it is fine. It drives me nuts.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days