Issue 384970: Linux: Please support XInput 2.1 true smooth/high-resolution scrolling
Reported by
ande...@mit.edu,
Jun 16 2014
|
||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.67 Safari/537.36 Steps to reproduce the problem: 1. Use two-finger scrolling on a Synaptics touchpad. What is the expected behavior? xorg-server 1.12 includes XInput 2.1 smooth scrolling events, so that clients can respond in real time to the smallest finger movements with pixel-precise scrolling. This support is present in Gnome applications including Epiphany (thanks to GTK+ 3.4), and it is now being added to Firefox <https://bugzilla.mozilla.org/show_bug.cgi?id=958868>. It really makes a huge difference in responsiveness, and Chrome should support it too. What went wrong? We get the same choppy, delayed, line-by-line scrolling that we’ve always had. (This is unrelated to the so-called “Smooth Scrolling” experiment in chrome://flags, which is just an animation effect that somewhat smooths out the line-by-line movements but does nothing for precision or responsiveness.) Did this work before? No Chrome version: 36.0.1985.67 Channel: beta OS Version: Flash Version: Shockwave Flash 14.0 r0 Bug 107328 had some work toward this goal by the Ubuntu people, but it seems to have stalled completely and is probably obsolete by now. , Jul 23 2014Yes. Just tried 38.0.2101.0 on Linux Mint 17. Firefox fixed this a while ago, comments and code might be interesting: https://bugzilla.mozilla.org/show_bug.cgi?id=958868 , Jul 23 2014Yes, this feature is still missing in 37.0.2062.20 (Official Build 283104) beta and 38.0.2101.0 (Official Build 284576) dev. , Aug 31 2014Does this still need fixing? I'd be interested at having a stab at fixing it. , Aug 31 2014Yep, scrolling is still choppy for me in Chromium 39 when scrolling with a trackpad. , Sep 3 2014Got it working - I'll send a CL for review. , Sep 3 2014That's amazing. I look forward to trying it out. :) , Oct 30 2014https://codereview.chromium.org/688253002 Currently there are a few bugs and no tests but they will come shortly. , Dec 22 2014
, Feb 6 2015Anything new on this? It would greatly enhance user experience on linux to have this kind of smooth scrolling. , Feb 6 2015I'm quite close to getting a patch set committed to fix this: https://codereview.chromium.org/688253002/ Just waiting for a final review / compatibility check with ChromeOS etc. , Apr 14 2015
Changing the status to Untriaged as this issue is being worked further and fix is already being reviewed. w.shackleton@ Kindly let us know the latest status of this issue. , May 16 2015Seems to be stuck in code review :/ Anything someone interested but not familiar with the codebase (such as myself) can do to help it along? , May 16 2015I'll chase up the reviewers and try to get this approved. , Jun 16 2015Is this still stuck in review? , Jun 23 2015I emailed the reviewers a month ago but still no reply :( I'll find some more people to add as reviewers to this , Jul 25 2015How many reviewers are needed for the patch to be merged? , Aug 13 2015Firefox Linux nightlies are built with Gtk+ 3 as of July 24, with working pixel scrolling. This should make its way into the Firefox 42 release in November. , Aug 14 2015Issue 429521 has been merged into this issue. , Aug 14 2015
Issue 519588 has been merged into this issue. , Aug 20 2015
Looks like this is being actively worked on. Assigning to the reviewer for now. , Aug 20 2015Issue 163852 has been merged into this issue. , Sep 3 2015I’m trying out this patch in an Ubuntu PPA package and sometimes upon starting scrolling with the right edge of an ALPS touchpad on my Thinkpad the viewport jumps up considerably (often to the top of the page) and then starts scrolling smoothly (from the wrong position further up the page). Could this be related to the patch? , Oct 4 2015I just tested the latest patch (which did not apply cleanly on the latest stable source, but was easy to fix), and the only problem I can find with it is that scrolling to switch tabs is also been affected. Tiny movements of my high resolution scroll wheel and my fingers on my trackpad cause Chromium to switch tabs when scrolling over the tab bar. The movement threshold required to switch tabs should be increased when using high resolution scrolling input. , Oct 20 2015The solution to this is to disable this feature on Linux, as it is on Windows and Mac (or possibly re-scale the tab scrolling). Should I include this patch too? , Oct 20 2015Please disable the tab scrolling "feature". , Oct 20 2015No, not being able to scroll tabs would be a major annoyance and UX slowdown and inconsistent with many other applications on Linux. , Oct 20 2015I use tab scrolling all the time, and would be very unhappy if it was removed. It seems like it shouldn't be that hard to just fix the bug. I tried to look into it, but I don't know much about how Chromium works. , Oct 20 2015Looking into it. , Oct 22 2015As a follow-up to my comment #23 above. I refreshed the patch to the latest version 7 on the review. On some pages (not all; but here yes, for example) when I click the page and then scroll, there is a jump in scroll position. I think it is resetting to an old scroll location. Does nobody else see this? , Oct 22 2015Hmm I can't repro. To test a hypothesis, on line 144 or so of x11_event_source.cc can you remove the xevent->xcrossing.mode == NotifyNormal condition from the if statement? (leaving just the other two conds and the or) and see what happens? (I'm on mobile so can't do a diff) , Oct 22 2015Hmm that won't do it actually. , Oct 25 2015So, nothing for me to try right now? , Oct 26 2015I don't think so - can you give steps to repro and devices used? , Oct 26 2015On this page (https://code.google.com/p/chromium/issues/detail?id=384970), click anywhere, commence scrolling with vertical edge scrolling on ALPS touchpad on Thinkpad X301. The page will jump to an initial scroll location and scroll smoothly from there. With no further clicks, it will smooth scroll correctly. After another click anywhere, it will jump again to the original jump position. So, it will reset to the same location every time. My touchpad has the following additional snippet in xorg.conf.d: Section "InputClass" Identifier "Pad options" Driver "synaptics" MatchIsTouchpad "on" MatchDevicePath "/dev/input/event*" MatchIsTouchpad "on" Option "SHMConfig" "1" Option "LeftEdge" "0" Option "RightEdge" "900" Option "TopEdge" "0" Option "BottomEdge" "640" Option "FingerLow" "7" Option "FingerHigh" "8" Option "MaxTapTime" "180" Option "MaxTapMove" "110" Option "VertScrollDelta" "8" Option "HorizScrollDelta" "8" # Option "CoastingSpeed" "12" # Option "CoastingFriction" "30" # Option "MinSpeed" "0.25" # Option "MaxSpeed" "0.50" # Option "AccelFactor" "0.015" # Option "EmulateTwoFingerMinZ" "127" # Option "EmulateTwoFingerMinW" "15" # Option "EmulateWheel" "0" # #Option "MaxTapMove" "2" # #Option "MaxTapTime" "50" # Option "VertTwoFingerScroll" "0" # Option "HorizTwoFingerScroll" "0" # #Option "FingerPress" "126" # Option "FastTaps" "1" # #Option "CornerCoasting" "0" Option "TrackstickSpeed" "0" Option "RTCornerButton" "0" Option "RBCornerButton" "3" Option "LTCornerButton" "0" Option "LBCornerButton" "0" #Option "TapButton1" "integer" # Option "PressureMotionMinFactor" "1" # Option "PressureMotionMaxFactor" "1" EndSection Some output from xinput $ xinput get-feedbacks "AlpsPS/2 ALPS DualPoint TouchPad" 1 feedback class PtrFeedbackClass id=0 accelNum is 5 accelDenom is 1 threshold is 5 $ xinput list "AlpsPS/2 ALPS DualPoint TouchPad" AlpsPS/2 ALPS DualPoint TouchPad id=11 [slave pointer (2)] Reporting 7 classes: Class originated from: 11. Type: XIButtonClass Buttons supported: 12 Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" None None None None None Button state: Class originated from: 11. Type: XIValuatorClass Detail for Valuator 0: Label: Rel X Range: 0.000000 - 1023.000000 Resolution: 0 units/m Mode: relative Class originated from: 11. Type: XIValuatorClass Detail for Valuator 1: Label: Rel Y Range: 0.000000 - 767.000000 Resolution: 0 units/m Mode: relative Class originated from: 11. Type: XIValuatorClass Detail for Valuator 2: Label: Rel Horiz Scroll Range: 0.000000 - -1.000000 Resolution: 0 units/m Mode: relative Class originated from: 11. Type: XIValuatorClass Detail for Valuator 3: Label: Rel Vert Scroll Range: 0.000000 - -1.000000 Resolution: 0 units/m Mode: relative Class originated from: 11. Type: XIScrollClass Scroll info for Valuator 2 type: 2 (horizontal) increment: 8.000000 flags: 0x0 Class originated from: 11. Type: XIScrollClass Scroll info for Valuator 3 type: 1 (vertical) increment: 8.000000 flags: 0x0 Is that informative? , Oct 26 2015Excellent, very useful. I'll try to reproduce this. , Oct 26 2015I couldn't reproduce but I've changed a few things to match more closely the behaviour of GTK3. Please can you try the latest patch set? Do you have any macro / other mouse software running? It's quite hard to figure out what might be causing this. , Oct 27 2015I’ve applied the latest patch set #9 and built chromium. Still the same issue. I don’t have any other stuff running besides that xorg.conf.d snippet. Here’s a (choppy) Screencast
, Oct 27 2015Here’s the version I’ve built: https://launchpad.net/~towolf/+archive/ubuntu/ppa/+packages , Nov 1 2015I built the package. Some thoughts. Ctrl+wheel to zoom is now unsuitably fast. This needs to slow down. Sometimes scrolling upwards instantly jumps me to the top of the screen. This happens more often (every few seconds) when scrolling up and down repeatedly (taking my hand off the touchpad before changing directions). Otherwise, pretty good. , Nov 21 2015Ctrl+wheel zoom fixed Scrolling jumping to top of screen also fixed. , Nov 24 2015Hi. Patch Set 11 sounded like it may have the issue I reported above. It seems it doesn’t, unfortunately. I tried to film my LCD this time to maybe make it more clear what is happening. When I clicked before a smooth edge scroll, I tried to mash the button loudly. Observe the scrollbar position. Video recording of bug here: https://youtu.be/VOk3BYQhTFc about:version 48.0.2560.0 (Developer Build) Ubuntu 15.10 (64-bit) with Patch Set 11 , Jan 6 2016Project MemberThe following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/49bcd394cf41b1c330c3ffbcae42ff5161352380 commit 49bcd394cf41b1c330c3ffbcae42ff5161352380 Author: w.shackleton <w.shackleton@gmail.com> Date: Wed Jan 06 17:38:22 2016 Made page zoom handling work with smooth scroll devices This CL is a smaller set of the CL https://codereview.chromium.org/688253002/ It fixes some broken functionality exposed by that CL. R=avi BUG= 384970 Review URL: https://codereview.chromium.org/1554253004 Cr-Commit-Position: refs/heads/master@{#367850} [modify] http://crrev.com/49bcd394cf41b1c330c3ffbcae42ff5161352380/AUTHORS [modify] http://crrev.com/49bcd394cf41b1c330c3ffbcae42ff5161352380/content/browser/web_contents/web_contents_impl.cc [modify] http://crrev.com/49bcd394cf41b1c330c3ffbcae42ff5161352380/content/browser/web_contents/web_contents_impl.h , Jan 11 2016Project MemberThe following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48 commit c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48 Author: w.shackleton <w.shackleton@gmail.com> Date: Mon Jan 11 20:08:58 2016 Implemented smooth scrolling using xinput2 in X11. Adds support for Xinput 2.1 smooth scrolling for hardware that supports it (such as touchpads and some mice). This provides similar behaviour to that seen on Mac OS X. BUG= 384970 Review URL: https://codereview.chromium.org/688253002 Cr-Commit-Position: refs/heads/master@{#368645} [modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/chrome/browser/ui/views/frame/browser_root_view.cc [modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/chrome/browser/ui/views/frame/browser_root_view.h [modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/base/x/x11_util.cc [modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/devices/x11/device_data_manager_x11.cc [modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/devices/x11/device_data_manager_x11.h [modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/devices/x11/touch_factory_x11.cc [modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/platform/x11/x11_event_source.cc [modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/x/events_x.cc , Jan 11 2016Code is committed, I think this can be closed :) , Jan 11 2016
Thanks for the update, marking as 'Fixed'. , Jul 1 2016
xinput2 support has been disabled in M52 due to issue 616308 and others. I'm reopening this bug to track turning it back on. , Jul 23 2016Can you please create a flag to reenable xinput2 support? I never had any problems with it, and now that it's disabled my scrolling is choppy and imprecise. (Fedora 24, Chrome Version 52.0.2743.82, Macbook Pro Retina Mid 2012) , Jul 23 2016It's on its way (I'm on holiday currently but next week). https://codereview.chromium.org/2153683002/ , Jul 26 2016
Issue 630489 has been merged into this issue. , Aug 25 2016
Issue 640501 has been merged into this issue. , Sep 20 2016The patch in comment #50 seems to have been merged on July 26. When is it going to be available in the stable release? I hope this can be fast tracked, since it was already reviewed and merged in the past, now it just has an additional "if" condition, if I understand correctly. , Sep 21 2016It’s in M54, branched at position 414607, currently in beta, and scheduled for stable release the week of 2016-10-18 (https://www.chromium.org/developers/calendar). , Sep 21 2016I was actually asking because I installed the "google-chrome-unstable" Arch Linux package, which is version 55.0.2859.0 dev, but it still has choppy scrolling :/ , Sep 21 2016It works for me in 54.0.2840.27 and 55.0.2859.0 on Ubuntu 16.10, so unless someone else here has an idea, you may want to file a new bug for that. , Sep 21 2016I just realized I was using Wayland and not X. Is this fix going to land on Wayland as well? , Sep 21 2016The code I wrote was X only - additional code is required for wayland. When I start using wayland I might get round to this :p , Oct 30 2016GNOME 3.22 just switched to Wayland as the default backend (you now have to explicitly choose X at login if you don't want Wayland). It would be awesome if high resolution scrolling could be implemented for Wayland as well :D , Dec 4 2016This seems to work on M54 now. Maybe open another bug for libinput support? This would cover wayland and newer X as well. Probably also need another bug for libinput kinetic scrolling. Chrome needs to implement this itself: https://wayland.freedesktop.org/libinput/doc/latest/faq.html#faq_kinetic_scrolling , Dec 4 2016OK I opened this: https://bugs.chromium.org/p/chromium/issues/detail?id=670992 Is another report really needed for the libinput kinetic scrolling? , Dec 28 2016william you wrote you use wayland, i suppose this is with gnome? how did you start chromium so it does use wayland, not X in wayland? , Dec 28 2016Yes this is with Arch Linux + GNOME + chromium (no customization of any sort). Arch Linux uses the latest GNOME version which uses Wayland by default. I didn't do anything to make chromium use Wayland apart from starting GNOME. Il mer 28 dic 2016, 13:40 rupert.t… via monorail < monorail+v2.2398624333@chromium.org> ha scritto: , Dec 28 2016By default, Chromium isn't built with Wayland support on Linux. This means you are likely using X11-based Chromium via XWayland. I'm guessing this means there is a limitation of XWayland that keeps the XInput 2.1 events from working properly, though it could be a bug in Chromium. I don't have my Fedora machine nearby with Wayland on it, so I can't debug this right now, but you could try to see if other X programs work properly or not with smooth scrolling on XWayland. Maybe xev ? , Dec 28 2016I can reproduce the issue when running KDE Plasma 5 o wayland. I don't get high-precision touchpad scrolling when Chrome runs in Xwayland , Dec 29 2016So the libinput stuff I mentioned is misleading. I don't think Chromium needs to use it. libinput is for the wayland compositor or X server to use. Next, I did some investigations. Xwayland does provide all the smooth scrolling info to clients, but provides only a single virtual pointer, with scroll increment = 1.0. Chromium specifically ignores devices with increment = 1.0. Probably Xwayland should change this? If there is a good reason not to, then maybe Chromium needs a patch. I'll try to look at Xwayland. , Dec 29 2016Issue 657104 has been merged into this issue. , Dec 29 2016It looks like Xwayland correctly sets the increment to 1.0. When I change it to 15.0 (which is the value I get under X directly), scrolling is very slow and does not match native X behavior. Probably Chromium needs to fix this to not filter out scroll increment 1.0 anymore. , Dec 29 2016The valuators under Xwayland seem to change at 1/10 the value than under X. When I middle-click scroll with the trackpoint, under X the valuators change in steps of 1.0. Under Xwayland, they change in steps of 0.1. So increment 1.0 is correct for Xwayland, and isn't a valid way of deciding to ignore XInput2 events as in ui/events/devices/x11/device_data_manager_x11.cc. , Dec 29 2016b794998819088f76b4cf44c8db6940240c563cf4 needs to be reverted, see issue 593453 and https://bugzilla.gnome.org/show_bug.cgi?id=750994. , Mar 3 2017Ping? The revert in #70 is still needed since this heuristic is broken on all but a particular X configuration, disabling smooth smooth scrolling unnecessarily. , Mar 31 2017Ping? It has been saying "Started" for quite some time now... :/ , Apr 4 2017
Hey all, this bug is really tracking the original work. I think the context and history is distracting rather than helpful so I'm going to close this one. agoode@, should we open a new bug or is this really about issue 593453 and we can use that? , Apr 4 2017I think issue 593453 probably covers it, since the issues on various systems all come from the heuristics that try to fix the missing scroll tick. , Aug 26For anyone who stumbles across this looking for libinput kinetic scrolling support, see https://bugs.chromium.org/p/chromium/issues/detail?id=763791 |
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by sdayala@chromium.org, Jul 23 2014