For a bit more context, see:  https://crbug.com/593453#c39  and  https://crbug.com/593453#c43 

+sadrul@: Do you know how this works on ChromeOS boards that use Wayland?

I believe wayland is used on all boards, but only for arc++ But we do not actually use wayland on any boards to receive input events from the system.

The issue is that the heuristic introduced in https://crrev.com/b794998819088f76b4cf44c8db6940240c563cf4 is brittle and incorrectly treats all XWayland axis input as discrete mouse wheel input. It should be reverted.

On Fedora, this heuristic is always wrong. Under X11, it claims that no screen devices are discrete mouse wheels, and this drops the first mouse wheel tick. Under XWayland, it claims that all scroll devices are discrete mouse wheels and fails to do smooth scrolling.

I don't think a straight revert is preferable. This does work correctly on X11, AFAICT. The first mouse wheel tick works fine with a clicky-wheel and I get smooth scrolling on trackpads. Reverting it will fix Wayland but break X11.

I agree though it's a hack we would like to see fixed. Any ideas on what's necessary to get this working cleanly more broadly?

The heuristic works only on distributions that use the deprecated xf86-input-evdev driver. As distributions migrate to xf86-input-libinput (as Fedora and Arch have), the heuristic will stop working.

Is there a metric to figure out what percent of Chrome usage is on X11 libinput or XWayland?

Debian/Ubuntu will eventually fail with the heuristic if they haven't already.

See http://who-t.blogspot.com/2015/01/xf86-input-libinput-compatibility-with.html

https://wiki.archlinux.org/index.php/Libinput

I don't think we have any metrics like that. FYI, I'm OOO next week but when I get back I'll try to find someone on the input team to look at it this quarter. 

Ubuntu 17.10 ships with Wayland by default (with X11 as a manual fallback), so I think it's safe to assume a large volume of future Linux users will be exposed to this issue.

You can confirm this on the latest 17.10 build here: http://releases.ubuntu.com/17.10/

Ok, thanks for the heads up. I'll take a look.

if a reliable heuristic isn't possible, couldn't there be a flag or something to allow the user to manually enable high resolution scrolling? For example, with firefox you can do this by setting the environment variable MOZ_USE_XINPUT2=1

I'm currently looking at a different Linux input bug so I'll take a look at this bug after that, while I've got the context paged.

Note that this heuristic is now ineffective on gLinux, because it uses libinput. The first mouse wheel event is lost as before.

(gLinux: https://debconf17.debconf.org/talks/44/)

thomasanderson@, I heard you're tracking a similar bug - is this related/known on your end? Could you take this over? input-dev doesn't really have the necessary expertise here.

Over to tonikitoo@ for wayland.

bokan@ contacted me about it a couple of months ago, but it ended up getting lost in my radar.

I will take a closer look this time.

Related/duplicate:  https://crbug.com/657104 

I can confirm MOZ_USE_XINPUT2=1 works fine for Firefox using Gnome 3.28. A chrome://flags option would indeed be appreciated! Gnome users are chunky- scrolling in Chromium for a long time now. Frankly this is the very last nuisance left for general use of Chromium / Chrome in gnome-wayland.

Has there been any progress on this?

Hi tonikitoo@, is that still on your radar?
Chrome is still not usable on Wayland because of this issue, any things we can to do move forward on this?
Thanks :)

Maksim has better chance to fix it atm.

"Chrome version: 57.0.2987.133  Channel: stable"

This is quite old already. Back at that time, you've used Chromium with X11 backend under XWayland, right?

The current effort is to run Chromium with Wayland backend natively. If you can try it as well, it would be great.

I tried with Chrome 69.0.3497.100 under Wayland (not XWayland), and the scrolling is still not smooth at all, compared to Chrome 69.0.3497.100 on Xorg.

emile@, it was a stable branch, right? I suppose it does not include the ozone layer and must use the old x11 backend, which means it uses XWayland.

To tell you more, the Wayland backend has not been shipped yet, and requires a ToT build.

In order to run it, you must pass --ozone-platform=wayland flag.

https://crrev.com/b794998819088f76b4cf44c8db6940240c563cf4 should be reverted I think. The heuristic is broken on all modern Linux distros in one of two ways:

- under X, it always uses xinput2
- under Xwayland, it never uses xinput2 (this bug)

Fedora reverts this change in their build of Chromium.
https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium-58.0.3029.96-revert-b794998819088f76b4cf44c8db6940240c563cf4.patch

*** UI Mass triage ***

adding labels for expert review.

Also tracking this bug in Ubuntu here: https://bugs.launchpad.net/bugs/1811219