Description of problem: When scrolling using the two-finger scroll on the touchpad of my ASUS N550JV, for example when reading a PDF in Evince, the scroll sensitivity is really high, leading to difficulties in positioning the view as desired. As a side effect, this high sensitivity leads to the kinetic scroll in GTK3 to make the view bounce up or down when the finger is lifted from the touchpad. This is due to the small movements registered when the finger is lifted, even if it was kept still before lifting it. Version-Release number of selected component (if applicable): libinput.x86_64 - 1.10.2-4.fc27 How reproducible: An ASUS N550JV is necessary, but other laptops with an "ETPS/2 Elantech Touchpad" may have the same problem. Steps to Reproduce: 1. Install Fedora 27 on an ASUS N550JV or boot with a live USB stick. 2. Open a PDF with Evince. 3. Try scrolling through the pages. Actual results: The movement through the PDF is really fast, allowing to scroll 6 pages (at 100% zoom) just moving the two fingers from top to bottom on the touchpad. When trying to center a particular page on the screen and then lifting the fingers from the touchpad, the view bounces up or down, due to the small scroll events registered when lifting the finger. Expected results: The pages should scroll at a lower speed (scrolling around 2 pages at 100% zoom when going from top to bottom on the touchpad), allowing for a more controlled movement of the view. When stopping the finger to center a certain page and then lifting it from the touchpad, the view should stay still. Additional info: My touchpad resolution is correct, I verified it using touchpad-edge-detector and fixed it adding the correct rule in hwdb.d. The touchpad dimension in mm reported by evemu-describe is now correct, but the scrolling problem is present nonetheless. (The correction to the resolution was small) The scrolling speed is not affected by the "Touchpad Speed" slider in GNOME Settings.
fwiw, libinput exports scrolling as an axis in a defined range and relation to pointer movement. We don't control what an application does with this, so if the scrolling is too fast that's either a toolkit problem or in the X case a xorg driver problem. You're likely on wayland so you may want to file this for GTK too (and possibly mutter) but I'm moving this to the xorg libinput driver for now because iirc it needs to be fixed there too.
Thank you for your reply. I can tell you right away that the behavior is exactly the same both with X and with Wayland. As a consequence, I will file this with GTK directly too. I have a question though. Are the values reported on the axis that represents the scrolling normalized in some kind of way, maybe against the touchpad physical dimension? If not, should this be done by libinput or there should be a setting, above in the stack, to regulate scrolling speed in your opinion? As a general information, observing the values reported by "libinput debug-events" for my touchpad, I am able to generate scrolling values up to "vert +/-150*" moving my finger as fast as possible.
I reported the same issue against GTK3 in bug 1559138.
I did further debugging into the issue myself and I arrived to the conclusion that, indeed, discussing about scrolling speed in this bug report is incorrect. I am writing this message to confirm my conclusions and have some clarification on how I should correctly report the issue upstream to the GTK project. Leaving out the scrolling speed, the real problem is that kinetic scrolling is triggered in GTK when lifting the fingers from the touchpad, even if they were still before being lifted. Looking at the output of "libinput debug-events", the problem is caused by the fact that often, when lifting the fingers, a further scroll event is sent before the "vert 0.00" which concludes the scrolling gesture. I assume that this is correct and it is simply caused by the "noise" created when lifting the fingers. As a consequence, that last scroll event should be sent by libinput but ignored by GTK. However, this does not happen at the moment. As for why the situation is under control with other touchpads and not with mine, I compared the behavior of my touchpad with the one of an XPS 13. Observing that spurious scroll event on both machines, its offset appears to be the smallest scroll offset that the touchpad is able to generate. On the XPS 13, the smallest scroll event that one is able to generate slowly moving the fingers on the touchpad, as observed in "libinput debug-events", corresponds to "vert 0.61". On my laptop, however, this event is "vert 1.41". As a consequence, the kinetic scroll generated on the XPS 13 is barely noticeable, while on my laptop is way stronger. I assumed this was due to the fact that the resolution of my touchpad was lower but, surprisingly, this is not the case. In particular, the ranges identified by "touchpad-edge-detector" and the physical sizes of the touchpads are the following: N550JV: Ranges: 3249/2223 Size: 104x74mm XPS 13: Ranges: 1216/680 Size: 101x56mm As a consequence, my touchpad appears to have a higher resolution and thus the minimum scroll event should be smaller than the one on the XPS 13, but this is not the case for some reason. Concluding, my problem is caused by the fact that the kinetic scroll algorithm in GTK is not ignoring a spurious scroll event that may be generated when lifting the fingers from the touchpad while keeping them still. The size of the event determines the fact that the problem is more noticeable on my laptop as compared to the XPS 13. As for why my touchpad generates larger minimum scroll events despite having a higher reported resolution, it may simply be that it is just pretending to have a higher resolution, for example, but I wanted to have feedback on this, just to be sure that there is no problem. If everything is in order and all that I described respects the expected behavior, I think this bug report can simply be closed and I will report a new issue to GTK upstream explaining in detail the kinetic scroll problem. As for the scroll speed, that is again a GTK problem, unrelated to the kinetic scroll one; my intention is to leave it alone for now.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.