GNOME Bugzilla – Bug 769696
Touch scrolling is too sensitive
Last modified: 2021-06-10 15:15:26 UTC
Found at https://bugs.launchpad.net/pantheon-terminal/+bug/1603878: It seems the terminal is now touch scrollable. You can scroll it, but the ratio of scroll to touch movement is not 1:1. Meaning that the window scrolls more than you move your finger. Expected: touch scrolling ratio should be 1:1.
See also bug 748012.
Someone with touch hardware needs to debug this (add some printfs to output the scroll events and their delta, and correlate what vte does with them on display).
I'm not sure but it seems highly likely that for each pixel you move your finger the view scrolls 1 whole row instead of the 1 pixel it should.
(In reply to Philip Goto from comment #3) > I'm not sure but it seems highly likely that for each pixel you move your > finger the view scrolls 1 whole row instead of the 1 pixel it should. I think it's more complicated, e.g. see the already linked other bug where we state that the speed even depends on the window height. 1 whole row instead of 1 pixel would, depending on the font size, probably cause a typically 20-30-fold ratio in speed, I would be surprised if the current situation was that bad. A touchpad reports floating point numbers for the amount scrolled, and is scaled in a way so that 1.0 can reasonably correspond to the 1.0 generated by one clicking unit of scrolling with a mouse wheel (which in VTE scrolls typically by 3-5 lines, depending on the number of rows). Of course the exact pointer speed is configurable under the desktop's settings, I'm not sure if it applies to scrolling too. For touchscreen I guess such setting shouldn't exist, and it's a reasonable expectation for scrolling to "just work" (at 1:1 speed). I don't know if it's implemented properly in other GTK+ apps, I don't know if GTK+ / X.Org / Wayland provide the necessary support for this, and as per bug 748012 comment 2 I'm not entirely certain. Whatever change is implemented, scrolling speed with mouse wheel or touchpad shouldn't significantly change from the current one. We'd even need to think about HiDPI displays where there's two different units called "pixel". This is not the kind of bug where one can jump straight into implementating the fix, it's the kind of bug where the state of the art (possibilities, help offered by GTK+ etc.) needs to be studied and understood first. Any help is highly appreciated. Christian already said he didn't have a touchscreen, I don't have either. So probably somebody else needs to step up and submit a fix (along with detailed enough information to convince us).
(In reply to Egmont Koblinger from comment #4) > 1 whole row instead of 1 pixel would, depending on the font size, probably > cause a typically 20-30-fold ratio in speed, I would be surprised if the > current situation was that bad. Yes it's that bad. I tested it a bit with the following results (tested with Tilix and a resolution of 3840x2160): With 200% scaling, moving my finger from the very top to the very bottom moves the content 1080 rows, which in my case equals 43200 pixels and thus is 20x too sensitive. Doing the same with 100% scaling moves it 2160 rows which still equals 43200 pixels and thus is also 20x too sensitive. Also noticeable when scrolling using the touchscreen is that rows always snap to the same locations, making it very likely that it scrolls per row instead of per pixel. > For touchscreen I guess such setting shouldn't exist, and it's a reasonable > expectation for scrolling to "just work" (at 1:1 speed). I don't know if > it's implemented properly in other GTK+ apps, I don't know if GTK+ / X.Org / > Wayland provide the necessary support for this, and as per bug 748012 > comment 2 I'm not entirely certain. I can confirm touch scrolling 'just works' in all other standard Gnome apps, but I don't know anything about the implementation.
I'm also experiencing extreme scroll sensitivity (about 1cm touchpad movement will scroll my browser window one screen). When I test with the libinput tester `libinput debug-gui` the scrolling looks like it responds reasonably, so perhaps duplicating whatever they're doing in the example app is a good idea. Looking at the example code [1] it does look like the deltas from libinput should be interpreted as pixels. [1]: https://gitlab.freedesktop.org/libinput/libinput/blob/7d0e1875701e750936b8f963db9182ca633df44e/tools/libinput-debug-gui.c#L629-635
whoops, my apologies. I just realized that this issue is regarding touch-drag scrolling with a touch screen, not two-finger scrolling with a touchpad. Feel free to delete my previous comment - sorry for the noise.
Possibly fixed by https://gitlab.gnome.org/GNOME/vte/-/issues/336 .
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2329.