New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 384970 link

Starred by 74 users

Issue metadata

Status: Fixed
Closed: Apr 2017
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Sign in to add a comment

Linux: Please support XInput 2.1 true smooth/high-resolution scrolling

Reported by, Jun 16 2014

Issue description

UserAgent: 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 <>.  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.
Labels: Needs-Feedback
 andersk@,Are you still seeing this issue with Latest chrome  i.e.,Latest Dev :38.0.2101.0 or Latest Beta :37.0.2062.20?

Comment 2 by, Jul 23 2014

Yes. Just tried 38.0.2101.0 on Linux Mint 17.

Firefox fixed this a while ago, comments and code might be interesting:

Comment 3 by, Jul 23 2014

Yes, this feature is still missing in 37.0.2062.20 (Official Build 283104) beta and 38.0.2101.0 (Official Build 284576) dev.
Does this still need fixing? I'd be interested at having a stab at fixing it.

Comment 5 by Deleted ...@, Aug 31 2014

Yep, scrolling is still choppy for me in Chromium 39 when scrolling with a trackpad.
Got it working - I'll send a CL for review.

Comment 7 by Deleted ...@, Sep 3 2014

That's amazing. I look forward to trying it out.  :)

Currently there are a few bugs and no tests but they will come shortly.

Comment 9 by, Dec 22 2014


Comment 10 by Deleted ...@, Feb 6 2015

Anything new on this? It would greatly enhance user experience on linux to have this kind of smooth scrolling.
I'm quite close to getting a patch set committed to fix this:
Just waiting for a final review / compatibility check with ChromeOS etc.
Labels: -Needs-Feedback
Status: Untriaged
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.

Comment 13 by Deleted ...@, May 16 2015

Seems to be stuck in code review :/

Anything someone interested but not familiar with the codebase (such as myself) can do to help it along?
I'll chase up the reviewers and try to get this approved.
Is this still stuck in review?
I emailed the reviewers a month ago but still no reply :(

I'll find some more people to add as reviewers to this
How many reviewers are needed for the patch to be merged?

Comment 18 by, Aug 13 2015

Firefox 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.

Comment 19 by, Aug 14 2015

 Issue 429521  has been merged into this issue.

Comment 20 by, Aug 14 2015

 Issue 519588  has been merged into this issue.
Labels: Hotlist-Input-Dev
Status: Started
Looks like this is being actively worked on.  Assigning to the reviewer for now.
 Issue 163852  has been merged into this issue.

Comment 23 by, Sep 3 2015

I’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?

Comment 24 by, Sep 3 2015

Here’s a GIF recording.
7.6 MB View Download
I 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.
The 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?

Comment 27 by, Oct 20 2015

Please disable the tab scrolling "feature".

Comment 28 by, Oct 20 2015

No, not being able to scroll tabs would be a major annoyance and UX slowdown and inconsistent with many other applications on Linux.
I 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.
Looking into it.

Comment 31 by, Oct 22 2015

As 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?
Hmm I can't repro. To test a hypothesis, on line 144 or so of 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)
Hmm that won't do it actually.

Comment 34 by, Oct 25 2015

So, nothing for me to try right now?
I don't think so - can you give steps to repro and devices used?

Comment 36 by, Oct 26 2015

On this page (, 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"

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?
Excellent, very useful. I'll try to reproduce this.
I 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.

Comment 39 by, Oct 27 2015

I’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
Screencast from 10-27-2015 12:31:53 PM.webm
3.5 MB Download

Comment 40 by, Oct 27 2015

Here’s the version I’ve built:
I 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. 
Ctrl+wheel zoom fixed

Scrolling jumping to top of screen also fixed.

Comment 43 by, Nov 24 2015


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:

about:version 48.0.2560.0 (Developer Build) Ubuntu 15.10 (64-bit)
with Patch Set 11
Project Member

Comment 44 by, Jan 6 2016

The following revision refers to this bug:

commit 49bcd394cf41b1c330c3ffbcae42ff5161352380
Author: w.shackleton <>
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
It fixes some broken functionality exposed by that CL.

BUG= 384970 

Review URL:

Cr-Commit-Position: refs/heads/master@{#367850}


Project Member

Comment 45 by, Jan 11 2016

Code is committed, I think this can be closed :)
Status: Fixed
Thanks for the update, marking as 'Fixed'.
Status: Started (was: Fixed)
xinput2 support has been disabled in M52 due to  issue 616308  and others. I'm reopening this bug to track turning it back on.
Can 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)
It's on its way (I'm on holiday currently but next week).

Comment 51 by, Jul 26 2016

 Issue 630489  has been merged into this issue.
 Issue 640501  has been merged into this issue.
The 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.

Comment 54 by, Sep 21 2016

It’s in M54, branched at position 414607, currently in beta, and scheduled for stable release the week of 2016-10-18 (
I 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 :/

Comment 56 by, Sep 21 2016

It 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.
I just realized I was using Wayland and not X. Is this fix going to land on Wayland as well?
The code I wrote was X only - additional code is required for wayland. When
I start using wayland I might get round to this :p
GNOME 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
This 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:
OK I opened this:

Is another report really needed for the libinput kinetic scrolling?
william 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?
Yes 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 <> ha scritto:
By 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 ?
I can reproduce the issue when running KDE Plasma 5 o wayland. I don't get high-precision touchpad scrolling when Chrome runs in Xwayland
So 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.
 Issue 657104  has been merged into this issue.
It 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.
The 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/

The revert in #70 is still needed since this heuristic is broken on all but a particular X configuration, disabling smooth smooth scrolling unnecessarily.

It has been saying "Started" for quite some time now... :/
Status: Fixed (was: Started)
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?
I 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.
For anyone who stumbles across this looking for libinput kinetic scrolling support, see

Sign in to add a comment