Mouse acceleration/speed in Stadia (in Chrome)

So here’s a weird one.

(This started on Leap 15.2 - I just upgraded to 15.3 to see if that resolved it, and it didn’t, FWIW).

Over a month ago, I was playing games in Stadia just fine using my mouse and keyboard (I also have a controller, but often times I just want to check something in one of the games without going through the whole controller linking process). Something changed about 4 weeks ago, though, and now when in the Stadia window, the mouse acceleration is completely off the charts. In the normal desktop, it’s just fine.

It seems to be possibly related to the polling interval, but I can’t seem to change it.

The mouse in use is a Wacom Intuos 4 tablet (using the mouse that comes with the tablet on the tablet). It uses its own driver, ‘wacom’, in the kernel. The tablet tracking mode is “absolute”. In gnome-tweaks, the acceleration profile is set to “adaptive” (but changing this doesn’t make any difference).

A bluetooth mouse (something I tried at the suggestion of the Stadia community) works just fine.

I’ve got a couple video captures showing the issue at https://stadia.google.com/capture/5ba8893e-a330-43d1-a114-0903fbb143fa and https://stadia.google.com/capture/e7e3f313-31ed-42fc-a8af-fdd5e78afe56 . You can also see what happens if I take my hand off the mouse completely in a capture at https://stadia.google.com/capture/60460de6-abb1-42d0-90bd-db185dbf5aea (each capture is ~30 seconds long).

I’ve tried the suggestions at https://wiki.archlinux.org/title/mouse_polling_rate - which is often referenced - but those changes made no difference (presumably because they involve settings for usbhid rather than the wacom driver).

Anyone have any suggestions or other information that might be useful to have to troubleshoot? I have no idea what changed (presumably a system update) or when (other than the rough timeline established above), but I’d like to try to figure out how to get this working properly again using the Wacom mouse (using my Apple mouse isn’t really a long-term solution :slight_smile: ).

Thanks!

Anyone? There used to be a way to do this, at least for cases where you installed a driver (such as synaptics). Missing that, how about System Settings -> Hardware -> Input Devices? There may be an adjustment there that affects your application.

I should have updated this with some additional info - the setup I’m using is a USB3 port, and the XHCI_HCD driver doesn’t support changing the polling interval.

What about creating bug report?

It’s not really a bug for the XHCI_HCD driver - the hardware architecture is designed specifically to reduce the need for periodic polling because the controller notifies the driver that an event took place. So rather than the driver having to ask the controller “did something happen” every 25 ms (or whatever), the controller lets the driver know “something happened” and the driver asks for information about what happened so it can act on it.

So the issue seems to be on Stadia’s end rather than in the Linux kernel (I suppose it could also be a Chrome bug).

Bug report for Google/Chrome/Stadia?

I raised a question in the Google Stadia forums already. They don’t have something like bugzilla that I’ve ever seen, so it’s been raised with them, but I’ve no idea how it’s being looked at or addressed. The suggestion from one of their forum experts (not an employee AIUI) was to use a non-USB 3.0 port on my PC to work around the issue.