Mouse wheel jumpy on scrolling

Question

I have a small issue that's really annoying me and wondering if there is a possible fix for it.

im using the latest distro of Ubuntu 10.10 and when scrolling up and down pages, especially in google chrome (also within folders etc) the page flickers up and down as I scroll.

There is no issue with the mouse itself as it works fine in other operating systems, but in ubuntu 10.10 it just lacks smoothness as well as it being jumpy.

To describe exactly how it just imagine that the page has 20 scroll jumps, you would normally scroll the mouse wheel once and it would go exactly one step down the page, but if I scroll about 5 clicks, it will jump back and forth.

Hope you can understand and can help me resolve this pain in the ...

Answer 1

Other solutions didn't work for me, however...

The fix for me for this (I had the problem for months!) was kinda surreal and like most folks I didn't believe it until I did it:

Turns out some MS mice have a scrollwheel bug.

Try unplugging the USB cable / dongle then plug back in.

That's it!

Now my mouse moves normally (one line at a time, not half a screen!)

This worked even though I use a 4-port screen/keyboard/mouse KVM box! Yeah!

Answer 2

I have a dual boot Ubuntu 11.10 and Windows 7 and just added a Microsoft Wireless 3500 and when I booted with Windows it installed some drivers for it. When I went back to Ubuntu the wheel scroll was half page jumpy. I unplugged the USB dongle and plugged it back in and all was back to normal. I'm thinking there are some settings that get set in the mouse itself from the Windows driver. But the solution above of just reconnecting the mouse works for me.

Answer 3

yes, unplug and replug the USB connection. it worked for me. after searching so many times for an answer, and tolerating it so long!

Answer 4

GTK dynamically calculates a good value for mouse wheel scroll rate (number of lines to be scrolled) depending on the size of the window. Unfortunately, it does not allow any customization yet and lost of bug reports have been filed about it.

By the way, if you are interested in testing what I said, just resize the window to be so small that it displays only one line. Try scrolling and you will see that it scrolls a single line everytime you scroll the wheel.

Answer 5

I had similar problem with quite new mouse (half year old). During scrolling up, the mouse mixed also some down events. And vice versa. I first thought the problem was in the driver. But the errors were visible also in Windows.

I ended up dismounting the mouse, which was quite clean. But when I blew hard into the wheel encoding component (there is tiny gap on top). Then it started generate events properly.

So I propose to everyone, try it on another OS and if it does not work there too, then try to "clean" the encoder even if it looks clean.

Answer 6

For me, the fix was to clean the inside of the mouse.

The proper way to do this is to carefully take it apart and remove hair and dust that had collected near the sensor of the mouse wheel. I just blowed really hard into the gap around the wheel. It worked immediately.

Answer 7

I had the exact same problem. Sometimes I'd scroll down and the screen would jump up.

OS: VERSION="20.10 (Groovy Gorilla)" Mouse: some generic USB wireless mouse

I tried another generic USB wireless mouse (from a different manufacturer) and the problem was even worse.

My up wheel is Button 5 so:

xev | grep -B 2 "button 5"

which reliably outputs two events everytime I scroll up one notch.

E.g.

--
ButtonPress event, serial 37, synthetic NO, window 0x7000001,
    root 0x7a5, subw 0x0, time 126819928, (119,90), root:(264,229),
    state 0x0, button 5, same_screen YES
--
ButtonRelease event, serial 37, synthetic NO, window 0x7000001,
    root 0x7a5, subw 0x0, time 126819928, (119,90), root:(264,229),
    state 0x1000, button 5, same_screen YES

It was odd that one mouse was worse than the other. Note that the bad mouse is so bad that sometimes you can be constantly scrolling up and it just keeps jumping around in the middle.

So, I then tried another mouse (identical to the first) and that worked perfectly.

I then tried measuring the battery voltage in the mouse to check if it could have been the signal.

Good mouse: 1.24V 40% Medium mouse: 1.32V 60% Bad mouse: 1.40V 70%

So the battery has nothing to do with the problem. I even swapped the battery in the good mouse with the battery in the bad mouse just in case there was a problem with my battery tester but that did not fix things.

Interestingly, on the bad mouse I found I was getting occasional "button 4" events, even when I was scrolling up. E.g. I was seeing many events with:

xev | grep -B 2 "button 4"

I opened up the mouse (not easy as it seems to clip together) and blew on the wheel.

Putting it back together it was significantly better which points to maybe dust on the scroll wheel. i.e. there was only the very occasional "button 4" event when scrolling up which could have been due to some residual dust I missed as I couldn't get into the mouse easily.

In summary, with the 3 mice I had, the problem turned out to be the mouse and dust on the wheel rather than Ubuntu. That is, the bad mouse which was struggling to even scroll at all is now working well.

Answer 8

I've got pretty much the same problem. When scrolling the wheel very very slowly, it works okay, exactly five lines at the time in gedit. When rolling faster, it jumps forth forth back forth back at random with the effect that you often are at pretty much the same place after scrolling the wheel one turn. In Windows, it works perfect without a driver. It's a Thrust mobile BT mouse.

I've got a wild guess what's the problem.

First off, this is a wheel with discrete positions on the wheel. This means that the wheel will go fast faster fast faster fast faster when scrolling fast, because the discrete positions function as a break.

I suggest that the hardware inside the mouse is not good enough to distinguish between back and forth and fast faster fast faster. I know the inner workings of an electronic mouse and it support such an explanation.

When two lights shines through spokes in a photo optic receiver and the latter can only know more or less light and from this have to decide what direction the wheel goes, it can be hard enough to write software for this job when the wheel is turning at the same speed. The explanation why it's not a problem even in Windows generic driver is that MS has had the same problem with their own poor made mouses.

Solution

Write a mode in the driver in which it will turn into when detecting fast changes between back and forth at the mouse wheel. In this mode the driver will discriminate opposite direction from the last one, lets say, in a ring buffer with five last elements.

Answer 9

Although blowing in the scroll wheel real hard worked for me, I got an alternative I've been using since I'm on Linux which could be useful to anyone that still got this issue: middle-click scroll, like the auto-scroll feature on popular browsers.

I found a Python script that tries to apply middle scroll ability to every mouse currently connected using xinput and libinput, you can find it here on GitHub.

Basically, the command is:
xinput set-prop [MOUSE_ID] "libinput Scroll Method Enabled" 0, 0, 1
with MOUSE_ID being the ID of your mouse seen in xinput list output.

Answer 10

I have tested that python script(https://github.com/brevalferrari/misc-scripts/blob/main/xinp.py) previously posted in this thread and made some of my own adjustments and tested them, specifically I played around with Coordinate Transformation Matrix, resulting in this code that worked for me:

#!/usr/bin/python3
from os import system
from subprocess import Popen, PIPE
from re import findall
Get Logitech Wireless Mouse device ID
mouse_ids = findall(
    r'\tid=(\d+)',
    str(Popen(
        'xinput list | grep -i "Logitech Wireless Mouse"',
        stdout=PIPE,
        shell=True
    ).communicate()[0])
)
if not mouse_ids:
    print("Error: Logitech Wireless Mouse not found!")
    exit(1)
for device_id in mouse_ids:
    # Disable/Enable natural scrolling (traditional scroll direction)
    system(f'xinput set-prop {device_id} "libinput Natural Scrolling Enabled" 0')
# Disable/Enable high-resolution smooth scrolling
system(f'xinput set-prop {device_id} "libinput High Resolution Wheel Scroll Enabled" 1')

# Disable/Enable horizontal scrolling
system(f'xinput set-prop {device_id} "libinput Horizontal Scroll Enabled" 0')

# Slow down cursor sensitivity (65% speed)
system(
    f'xinput set-prop {device_id} "Coordinate Transformation Matrix" '
    '0.550000, 0.000000, 0.000000, '
    '0.000000, 0.550000, 0.000000, '
    '0.000000, 0.000000, 0.500000'  
)

print(f"Applied settings to Logitech Wireless Mouse (ID: {device_id})")

Basically the speed is reduced to 60%. I don't exactly know what other settings do. I just tested different configurations until I got a somewhat satisfactory result. There is still some stuttering, but it's much less than before.