Change scroll wheel speed

Interesting problem Jim.
You see, the wheel is not a wheel at all (its not analog), in fact wheel movements are seen as button presses (its digital).
If you open the X event monitor (from terminal just type xev) and you go with your pointer within the white window, you will see that at each movement of the wheel there is a button press/release event (depending on your xorg.conf, usually 4 and 5).

Can you check this with the two mouses?

Once we see what happens we will tackle it from there.

Here is a couple lines from that.

ButtonRelease event, serial 27, synthetic NO, window 0x3e00001,
    root 0x186, subw 0x0, time 2359624, (84,114), root:(89,955),
    state 0x810, button 4, same_screen YES

ButtonPress event, serial 27, synthetic NO, window 0x3e00001,
    root 0x186, subw 0x0, time 2361760, (84,114), root:(89,955),
    state 0x10, button 5, same_screen YES

Scroll down is button 5 and up is button 4.

Oh, and here is the relevant section from xorg.conf

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "ImPS/2"
 Option "ZAxisMapping" "4 5"
 Option "Emulate3Buttons" "true"

OK, but do you see a different behaviour from the two mices?
On mine the two events (press and release) are simultaneous and there are only two events per wheel "click", like this:

ButtonPress event, serial 31, synthetic NO, window 0x2c00001,
    root 0x4d, subw 0x0, time 2467884848, (74,108), root:(81,158),
    state 0x0, button 5, same_screen YES

ButtonRelease event, serial 31, synthetic NO, window 0x2c00001,
    root 0x4d, subw 0x0, time 2467884848, (74,108), root:(81,158),
    state 0x1000, button 5, same_screen YES

See, the time is the same (within resolution of the timer).
Try also changing the protocol, perhaps its better with ExplorerPS/2.

Some other fancy protocols to try:

Auto, Microsoft, MouseSystems, MMSeries, Logitech, MouseMan, MMHitTab, GlidePoint, IntelliMouse, ThinkingMouse, ValuMouseScroll, AceCad, PS/2, ImPS/2, ExplorerPS/2, ThinkingMousePS/2, MouseManPlusPS/2, GlidePointPS/2, NetMousePS/2, NetScrollPS/2, BusMouse, SysMouse, WSMouse, USB, VUID, Xqueue

PS. If you have a 3 buttons mouse you may want to change Emulate3Buttons to false and I would also add these 2 lines:

Option "Buttons" "5"
Option "ButtonMapping" "1 2 3"

Thanks for the help. I changed the protocol to explorer, changed emulate to false and added the options. There doesn't seem to be any change. My mouse doesn't "click" when rolling the wheel, but when just barely moving it, it records a lot more than 2 events.

ButtonPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x186, subw 0x0, time 6466576, (160,163), root:(165,213),
    state 0x10, button 5, same_screen YES

ButtonRelease event, serial 30, synthetic NO, window 0x3c00001,
    root 0x186, subw 0x0, time 6466576, (160,163), root:(165,213),
    state 0x1010, button 5, same_screen YES

ButtonPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x186, subw 0x0, time 6466576, (160,163), root:(165,213),
    state 0x10, button 5, same_screen YES

ButtonRelease event, serial 30, synthetic NO, window 0x3c00001,
    root 0x186, subw 0x0, time 6466576, (160,163), root:(165,213),
    state 0x1010, button 5, same_screen YES

ButtonPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x186, subw 0x0, time 6466576, (160,163), root:(165,213),
    state 0x10, button 5, same_screen YES

ButtonRelease event, serial 30, synthetic NO, window 0x3c00001,
    root 0x186, subw 0x0, time 6466576, (160,163), root:(165,213),
    state 0x1010, button 5, same_screen YES

ButtonPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x186, subw 0x0, time 6466576, (160,163), root:(165,213),
    state 0x10, button 5, same_screen YES

ButtonRelease event, serial 30, synthetic NO, window 0x3c00001,
    root 0x186, subw 0x0, time 6466576, (160,163), root:(165,213),
    state 0x1010, button 5, same_screen YES

The bluetooth mouse I use with my laptop works like yours. It only records two events for a "click" when rolling the wheel. I suspect this is probably hardware related but I'd like a way to configure it. I'm pretty sure there are ways to configure the scroll in that "other" OS. The mouse setting under preferences, however, don't deal with scrolling. Do I have to find the right xorg options to fix this or is it hardware and I'm just out of luck. I've always assumed the latter but it seems like there should be a way to configure this.

What is the exact mouse make and model.

For example, mine is Microsoft Intellimouse Explorer 2.0 model 1007

Mine is a Microsoft wireless optical mouse 2.0. It came with with a keyboard and was part of a package. I don't remember the mane of the package but it was something like wireless desktop 3000.

OK, I can see 3 ways to solve this:

1) On the kernel side we should find a way to pass some options to the module so that the events are filtered.
2) On the Xorg side perhaps it is possible to implement a filter.
3) In Gnome we could change the default "slide", ie. the amount of movement associated with the events.

I personally think 1) is the best solution, if we can find it.
Now, looking at the psmouse module with modinfo I found this parameter:

smartscroll: Logitech Smartscroll autorepeat, 1=enabled (default), 0=disabled. (bool)

I wonder if this will do the job?

You can try passing this in /etc/modprobe.d/options as:

options psmouse smartscroll=0

I think reloading the module should be enough, otherwise reboot:

sudo modprobe -r psmouse
sudo modprobe psmouse

It this doesn't work perhaps we should be looking at quirks in usbhid.

Cesare,

Thanks for trying. I added the option to /etc/modprobe.d/options but it did seem to have any effect. I even rebooted to make sure it was loaded. So far nothing seems to have any effect. The slightest movement of the scroll wheel still produces at least 6 events. I'm going to play around with some of the fancy protocols and see what happens. I'm also starting to wonder if this might not be a bug. I wonder if it's specific to this one mouse or if others might have a similar experience.

Thanks Cesare Tirabassi, that solved my question.

No, no real luck with the protocols. I thought the microsoft one made sense since it's a MS mouse but that totally broke the mouse. It just stayed in the upper left corner and jumped around a bit.

I think there needs to be a way to manipulate this in gnome (I wonder if kde has an option?). If it's specific to this one mouse then oh well, but I still think there needs to be a way to edit this. I'm going to file a bug report and see what happens. Maybe something will get added in the future.

I'm marking this solved since I don't think there is much else to do. If you have any thoughts please add them but otherwise I'll just deal with it. Thanks for the help.

Not a fix, but you can enable 'autoscrolling' which will enable you to use the middle mouse button press to scroll. It is under Firefox>Preferences>Advanced>General and I find it much more efficient for longer web pages then the traditional scroll wheel.

Though the odd thing is that being such a popular product line, haven't seen a ton of complaints. Have you tried it in a windows environment to rule out hardware failure? I could not see a reason that the scroll wheel action would cause 4 press release cycles with such a small movement.

Best Regards,
Williamts99

Williamts99, thanks for the ideas. The autoscrolling works well for long pages but my problem is being able to scroll small bits at time - like when reading something. It moves too much for just a little scroll and I lose my place and it often goes right off the screen. I did try in windows like you suggest and there isn't a problem there. In fact, it scrolls too little. I had to use the mouse configuration to up the number of lines scrolled with each click.

It sounds to me that with that mouse they were just messing with compatibility, of course the reasons for this can be varied.

Could you paste the mouse section from cat /proc/cat /proc/bus/input/devices

Best Regards,
Williamts99

I am also having this same problem and it's driving my INSANE! My mouse is also microsoft. Microsoft Wireless Laser Mouse 5000. This really should be fixed so that all users in the future don't give up ubuntu for such a silly, but serious reason of scroll speed. It really makes browsing and reading a total pain.

I have a Microsoft Wireless Laser Mouse 5000 that I use with KDE and xfce. I used to have this problem but finally got it to go away, but maybe not permanently...

Here's the problem. (This is all from memory so it may sound a little unclear.) This mouse's receiver (or maybe the mouse itself?) seems to save some sort of state. The problem was that I had used this mouse in Windows with the supplied Windows driver and it likes to have a high resolution of events or something like that. So it set the mouse up that way. When I moved the mouse over to my linux box *and reset the mouse* the scroll button did exactly what you are describing.

I read somewhere that plugging the mouse back into a windows box and then back to the linux box quickly would fix it. Sure enough that seemed to reset the mouse. Now, at that point I'm not sure if the windows box that I used had the special driver from Microsoft installed or not. (In fact I think the last time I had to do this it was with a Windows parallel image.) Anyway, the point is this mouse needs to be reset by talking to a windows box for a little bit.

It's a pain, I know, but I haven't had to do it for a couple of months now, so it seems to be sticking this time.

I have a MS Wireless Desktop 6000 v2 and it has the exact same multiple-event problem described by the other users above. For the most part I've learned to live with it and I think others doing the same is the reason why there aren't more reported problems. I dual-boot into Windows every now and then, so I have tried cygnl's suggestion repeatedly (without knowing it). I will try actually unplugging the receiver and plugging it in again next time I boot into Windows.

Regardless, there really should be some way of handling this - either in the kernel or (as would be the logical place IMHO) in X. Some sort of mechanism to describe what should be triggered by a mouse event or series of mouse events, probably directly in xorg.conf (although one could certainly argue that xorg.conf complicated enough already).

More mouse options exposed in Gnome is also desperately needed, IMHO.

Just to clarify a point Cesare Tirabassi made earlier:

No, the mouse wheel isn't a "wheel", as in an analog device. But neither is the "ball" or whatever mechanism ones particular mouse uses to relay (x/y) translation. This is also just a series of event-triggers and here there is no problem in implementing a "sensitivity" option (and even acceleration & min-threshold). Even an old ball-and-chain mouse had discretized movement (usually implemented via a wheel that was turned as the ball rolled, causing "events" at regular intervals - e.g. by an optical sensor detecting when gaps in the wheel were aligned with a light source).

Implementing a sensitivity adjustment for the scroll wheel is thus exactly the same, in principle, as for the basic x/y translation of the mouse. (And, like with the mouse, it should be implemented, probably in X, and exposed by the Gnome mouse options).

I own a Microsoft wireless laser mouse 5000 and had the same problem after dual booting Windows Vista. When booting Ubuntu again my scroll wheel was more or less unusable.

In Ubuntu (!) again I just unplugged the receiver and plugged it in again as fyo described (by reading fyo's explanations I thought I must do the plugging in Windows, so this is just for clarification). This solved the problem for me.

The removal and re-insert trick worked for me too! Pfew, that one was really driving me nuts.
Microsoft wireless laser mouse 5000 on dual boot system Windows XP and Ubuntu Gutsy

Just unplug USB and replug. MS Wireless 3000 (Wireless Optical Mouse 2.0) via Belkin KVM.

I upgraded my mis-installed i586 FC6 to i686, rebooted to XP partition (had to get a file) then back to FC6 - and got supersonic scrolling. Unplug/plug USB (from KVM) and back to normal.

Cross-booting never affected it before, so I can only assume the kernel upgrade (better CPU management, etc.) caused the change.

Regards,
oh4real

I know that this thread is technically considered closed, but I have something to add after many many weeks of trial and error.

I too had a similar problem with my Microsoft Wireless Laser Mouse 5000 which was bundled with my wireless keyboard.

My problem was that I could get my scroll wheel to work or my back (or forward) button to work, but never at the same time. And when the scroll wheel was functioning, it would scroll entire pages at a time with no way to correct how many lines per scroll.

With all due respect to all the given information above, the problem is not the receiver, or the mouse, or the keyboard or any combination thereof. It's was actually a really simple fix to the xorg.conf file. There is no need to unplug and replug the mouse or pass info to the kernel or any of that.

Uh... This mouse technically uses 9 buttons. In fact, many of today's mice use more than 5 buttons. (The scroll wheel can depress (that's 1 click), can move side to side (that's 2 more) then the back and forward buttons (we are up to 5 now), the scroll up and down (7) and the right click and left click (9 total).

I simply changed my xorg.conf to look like the following: (please don't forget to back up your current working configuration just in case)

Section "InputDevice"
        Identifier "Configured Mouse"
        Driver "mouse"
        Option "CorePointer"
        Option "Device" "/dev/input/mice"
        Option "Protocol" "ExplorerPS/2"
        Option "Buttons" "9"
        Option "ZAxisMapping" "4 5"
        Option "ButtonMapping" "1 2 3"
        Option "Emulate3Buttons" "false"
EndSection

Now I have both the back (and forward) button working AND the scroll is normal (3 lines) all at the same time (not at different configurations).

I hope this helps someone else out there who continues to have similar problems.

Thanks for your time.

Ken in Arizona

Ken, your problem with a misconfigured xorg.conf has nothing to do with the bug experienced by others.

You could probably replicate the bug if you compared the output of "xev" before and after booting your system into Windows (XP at least and drivers could matter as well). To observe the bug, it's critical that the transceiver not be completely powered off (which would be equivalent to unplugging it). That is, the system must not be turned completely off, but rather left in the off state that virtually all unmodified desktop PCs sold today use (where the motherboard still receives some power, allowing for things like WOL and soft-on).

I have all my buttons working properly (because my xorg.conf is configured properly - very similar to yours), but that doesn't change the FACT that prior to booting into WindowsXP, my mouse (i.e. my receiver) produces exactly 1 ButtonPress event and 1 ButtonRelease event when scrolling one unit. After booting into Windows, *multiple* such events are produced. That makes it *impossible* to scroll just one line at a time (since X thinks multiple lines have been scrolled).

The proper solution is not to implement a divisor or filter in X (or KDE/GNOME) to adjust the sensitivity (although that might be nice to have in general), but rather to fix the driver to account for the odd behavior of a range of Microsoft wireless mice (transceivers). This might involve sending some sort of "reset" to the transceiver on driver load.

Please read the whole thread (or, in this case, just the first few messages) before concluding (and possibly leading others to conclude) that the problem everyone else is having doesn't exist.

You write "with all due respect to the information given above", insinuating that you have read the information and that it is incorrect. That is false, at least the latter part of it (since I don't know if you've actually read it).

May I thank you for such a wonderfully accusitory form of a reply?

I think I did read the whole thread and even the bug report that went along with it.

As I read, the person had a mouse very similar if not the same one that I have and someone had erroneously told him to add options buttons 5 to his xorg.conf since the mouse has many many more. Of course his output would show multiple "clicks" when the wheel is used since the right number of buttons has not been properly configured. And since any driver or such needs to have the buttons properly mapped before it can interpret the signals, then it stands to reason there only needs to be a way to communicate that information PROPERLY to the kernel.

If you had read my entire post you would have seen that I had a similar problem with scrolling entire screens BEFORE fixing the xorg.conf.

Since my fix worked, I posted my results. Obviously I'm just a dumb newb who doesn't know any better. (There goes 15 years of computer hardware experience down the drain.) Please forgive my foolishly wanting to try to help.

I am sorry that you are still having a problem which was not resolved by fixing the xorg.conf. HOWEVER, Jim should not have been given incorrect information regarding the number of buttons. Even wired mice automatically (and correctly) configured by linux will show more than 5 buttons on many mice.

I am surprised you never caught that, but instead decided to chastise me by telling me I don't read everything before posting something. Oh and the Wireless 6000 v2 is (by the hardware and drivers at least) vastly different than the 5000 series, but you knew that right?

If yours is truly a bug, then I guess my question at the end of my post would be a resounding no. I accept that, however, for many end user type people it could well be a simple mis-configuration.

I will now stop watching this thread.

Thank you for your time.

And for the Record, I did try this fix on several mice that never worked under linux. Here is the list:

Microsoft Wireless Laser Mouse 5000
GE Optical Mouse WK2803 (usb mosue) (yes this wired mouse never configured correctly automatically for some reason)
Dynatech Wireless Mouse
No name off the shelf optical mouse (no drivers were supplied with the mouse and no information regarding manufacturer could be found outside of or inside the mouse)(go figure. must have been a bad year for the manufacturer)
(and even) Microsoft Optical v2 (5000 series) (the only diff between the optical and the laser is the emitting diode and reader is changed to laser, but the 6000 series involves new circutry.)
(Yes I know I have a small parts store in my house.)

With the exception of the Microsoft mice, all had 7 buttons (Right, Left, Back, Forward, scroll up, scroll down, press scroll button in = 7 (not in that order)). The Microsoft mouse had 9 buttons (Right, Left, Back, Forward, scroll up, scroll down, press scroll button, move scroll button left, move scroll button right, = 9 (not in that order))

Also what's important to remember is that when ever there is an update to the X11, the xorg.conf is usually overwritten. I know Ubuntu recently started asking if the user wanted the file overwritten. Many people however, simply click their way through confirmations and don't bother to read what is being presented to them and so their xorg.conf is rewritten back to the default which gets rid of all modifications made. Some people are savy enough to figure that out and make the changes back to what they wanted.

As to the need to have a way to control the number of scrolls per event, That is not a bug. It's a wish since there are many ways to configure the number of scrolls in Linux. In Firefox for example, about:config will get to you a very comprehensive configuration screen where you can scroll down to the mouse events and change many things. Other events are handled by other configuration protocols, but the problem here is that many different flavors of linux use different configuration files and even place them in different locations. What is in my /etc/X11 may be in someone else's /etc/X/X11/xserver.something.something.etcettera.../differentdirectory/etc... There could even be differences in the locations of things within the same distribution. User x is a pro and user z is an enduser. User x likes to put things in special places and user z has no clue. User x puts things in non-standard locations and even uses the /opt where as the default for Ubuntu is to not use that particular directory. User x likes to compile whereas user z likes to have things done automatically for him/her. There is no right or wrong in Linux so long as it works.

AND correct me if I'm wrong, but all you are asking for is a graphical way to adjust the number of lines from a scroll. This bug of having to unplug and replug the wireless receiver belongs in a different bug report and if I'm not mistaken has already actually been reported as a problem with the hardware and not the software. It is not part of a graphical mouse adjustment protocol wish.

But if the resulting wish and by default (since it's included in all these posts) bug can be fixed by properly configuring a file, then again, it's not a bug at all.

So yes, fyo, I did read and do read many things before I made my posts. I have worked in the hardware industry for over 15 years, and have programmed a portion of those years.

Some problems can be solved by the most simplest of solutions.

I now sit back and wait for the fur to fly.

Thank you for your time.

http://brainstorm.ubuntu.com/idea/3214/

http://ubuntuforums.org/showpost.php?p=3951507&postcount=6

So theoretically this is possible by adding
Option "VertScrollDelta" "6"
to mouse section in /etc/X11/xorg.conf

But I just try this and did not work.

Cesare,

Thanks for the about:config tweaks, much appreciated. It was really beginning to annoy me that the scroll wheel was too slow, now I've set it to 20 it's so much better.

Thanks again.

With all due respect to Ken, this problem is not related to a misconfiguration of the InputDevice in xorg.conf. If it was, then unplugging and then re-connecting the wireless mouse transceiver would have no effect. But in fact, this does solve the problem.

I've been using Ken's suggested InputDevice configuration for over a year now. And every time I reboot into Windows, MS somehow reconfigures the wireless mouse transceiver to send multiple scroll wheel events when the user moves the scroll wheel once. I've no idea why they do this. When rebooting back into Linux the transceiver retains this configuration and does the same thing with X. This is why people are seeing multiple ButtonPress and ButtonRelease events when scrolling the wheel once.

I can confirm that unplugging and then re-connecting the wireless transceiver resets its. Scrolling then is back to normal.

I suspect that a kernel usb inputdev developer needs to look at this so that they can reset the usb mouse when the module is loaded and if it is a MS wireless mouse. Until then the only work-around is to unplug and then re-connect the USB wireless transceiver.

so i have to u-plug, and re-plug my usb connector every time i boot into ubuntu?

this is not solved. it should still be open

I agree .. it's not solved; a fix for firefox is not a fix for gnome.

I would beg that Ubuntu copies on Windows once again. Windows has a nice GUI to adjust the mouse scroll wheel.

We hope to see this in Ubuntu.

Case shall be closed then the GUI has been implemented.

I first came upon this problem six years ago, but from a different angle: After buying a Microsoft "Wireless Optical Mouse 2.0" I *wanted* smooth mouse scrolling in Linux like I had in Windows. After some rebooting, deducing and USB sniffing, I concluded two things:

- The Microsoft smooth scrolling mice default into coarse scrolling at power up and smooth scrolling must be enabled by a driver -- this is why the mouse reports "too many" scroll events in Linux after having booted into Windows, and why the behavior reverts to normal after replugging the mouse.

- XF86 was collapsing multiple scroll events into a single button event, meaning one had to scroll slowly or have your scrolling truncated by the mouse driver.

I made a kernel usb driver patch (attached) to enable the smooth scrolling behavior and an XF86 mouse driver patch to dispatch all the scroll events correctly. The patches were made against whatever was the cool kernel in Sept 2004, and whatever the XF86 was at the time. I didn't pursue submitting the USB patch for inclusion into the kernel because the usb-hid driver was not the right place to change scroll behavior, and it wasn't clear there *was* a right place... And the XF86 patch was useless without the USB patch.

I am interested in the X (X.org this time) scroll wheel behavior again because I use an Apple Magic Mouse via (customized) synergy++ and have run into the limitations of the X server again.

This usb driver patch won't fix the too-many-scroll-events problem--in fact it will *cause* the problem--but anyone who wants to pursue this further can use this as a starting point:

diff -u input-orig/hid.h input/hid.h
--- input-orig/hid.h 2004-09-21 00:30:07.000000000 -0700
+++ input/hid.h 2004-09-19 21:59:44.000000000 -0700
@@ -211,6 +211,7 @@
 #define HID_QUIRK_2WHEEL_MOUSE_HACK_BACK 0x080
 #define HID_QUIRK_2WHEEL_MOUSE_HACK_EXTRA 0x100
 #define HID_QUIRK_2WHEEL_MOUSE_HACK_ON 0x200
+#define HID_QUIRK_SMOOTH_WHEEL 0x400

 /*
  * This is the global environment of the parser. This information is
diff -u input-orig/hid-core.c input/hid-core.c
--- input-orig/hid-core.c 2004-09-21 00:30:07.000000000 -0700
+++ input/hid-core.c 2004-09-20 05:32:07.000000000 -0700
@@ -1439,6 +1439,9 @@
 #define USB_DEVICE_ID_1_PHIDGETSERVO_20 0x8101
 #define USB_DEVICE_ID_4_PHIDGETSERVO_20 0x8104

+#define USB_VENDOR_ID_MICROSOFT 0x045e
+#define USB_DEVICE_ID_MICROSOFT_WIRELESS_OPTICAL_MOUSE_2 0x008c
+
 static struct hid_blacklist {
        __u16 idVendor;
        __u16 idProduct;
@@ -1521,6 +1524,7 @@
        { USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD, HID_QUIRK_BADPAD },
        { USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD },

+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MICROSOFT_WIRELESS_OPTICAL_MOUSE_2, HID_QUIRK_SMOOTH_WHEEL },
        { 0, 0 }
 };

diff -u input-orig/hid-input.c input/hid-input.c
--- input-orig/hid-input.c 2004-09-21 00:30:07.000000000 -0700
+++ input/hid-input.c 2004-09-20 20:12:30.000000000 -0700
@@ -619,6 +619,15 @@
                }
        }

+ if (hid->quirks & HID_QUIRK_SMOOTH_WHEEL) {
+ /* enable smooth scrolling wheel */
+ __u16 smooth_magic = 0x303;
+
+ int res = usb_control_msg(hid->dev, usb_sndctrlpipe(hid->dev, 0),
+ USB_REQ_SET_CONFIGURATION, USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_OUT,
+ smooth_magic, 0, &smooth_magic, sizeof(smooth_magic), HZ * USB_CTRL_SET_TIMEOUT);
+ }
+
   /* This only gets called when we are a single-input (most of the
         * time). IOW, not a HID_QUIRK_MULTI_INPUT. The hid_ff_init() is
         * only useful in this case, and not for multi-input quirks. */

I just purchased an HP Pavilion dm4-2060ef and had this problem. I am using Kubuntu 11.04 (yes, unity sucks so bad I moved back to KDE). This problem disappeared for me after installing the restricted AMD Radeon drivers - not a problem for me as I don't *really* care about having FOSS *drivers*... and scrolling is now very smooth (wireless M$ 3000 mouse).
A++

Microsoft Wireless Mobile Mouse 1000 -- same issue
A kernel patch is not a solution for many users

Just bought a Microsoft Wireless Mouse 5000, and having the same problem.

I believe that the comment of Richard Moats is accurate: the Windows driver seems to enable smooth scrolling for the mouse, which is translated to multiple scroll events, which are handled correctly by the Windows driver but "incorrectly" by the xorg driver.

You could note that, in Windows, scrolling is actually smooth: if you scroll the wheel slowly, the page scrolls just a bit; if you scroll the wheel quickly, the page scrolls more quickly. Overall, the behavior in Windows is very pleasing. Unfortunately, in Linux, "smooth" scrolling is too fast and "coarse" scrolling seems a little slow to me and acceleration is not what I would expect...

I can confirm the behavior with a "Microsoft Wireless Laser Mouse 6000". The scroll wheel worked "normally" (coarse scrolling) under both Ubuntu and Windows XP, even across reboots from one to the other. However yesterday I upgraded to Windows 7, and after a hot reboot from Windows to Ubuntu, the scroll speed and sensibility had become unusably fast in Ubuntu. Unplugging and replugging the mouse reverted back to the previous speed.

This is still a problem in the 2011, with the Unity.

Why is this marked as «Solved»? Please re-open.

HOLY CRAP! Unplugging it and plugging it back in fixed it! I can't believe it! WOOHOO.

Still, they should fix the drivers/firmware.

@Dennis J West

Unplugging it does not fix it for everybody — in my case, for example, it made scroll speed dramatically lower, but it is still very inconvenient.

"HOLY CRAP! Unplugging it and plugging it back in fixed it! I can't believe it! WOOHOO."

Yeah, it works!

Well I'll be.. The unplug/replug actually fixed mine too.. Shouldn't have to do that though. :/

Mine is microsoft wireless keyboard 3000 v2 and microsoft wireless mouse 5000..with the same problem in dual booting windows and linux...unplug ang replug works..

It works, but this is not really a fix.

What do you propose for dual booting users, crawling under the table to unplug adapter every time different OS is booted?

Please do not tell me this will be open for a few more years.

Too bad I cannot mark it as "not solved".

I have developed a userland application to reset this.

You can use git to grab it. The following command will do the trick. I am releasing a source code .tar.gz, ubuntu package, and fedora rpm soon.

It fixes the vertical scroll wheel issue with Microsoft models 3500 and 5000, and possibly others:

Until then, the source code is available here:

git clone https://github.com/paulrichards321/resetmsmice.git
./configure
make
sudo make install
sudo resetmsmice-enable-boot.sh --upstart

If you don't have git you can also grab the source here:

http://sourceforge.net/projects/resetmsmice/files/

Just untar/ungzip the file and follow the above commands.

I will be making ubuntu and fedora packages shortly.

Hi to you all. I am new to the linux World. I have a Microsoft wireless optical mouse 2.0 and a Microsoft Wireless Keyboard 3000 which are both a connected with a Microsoft WIreless Desktop Receiver 3.1 on my PC. I am dual booting Windows 7 with Ubuntu 12.04. Everything works perfectly except for the same problem with mouse wheel speed where you have to unplug the receiver and replug it for the wheel to operate normally. It's a same that such a good OS like Ubuntu doesn't offer some kind of Control on mouse wheel speed. Anyway I tried Paul Richard's program (congrats on your work and the time you put on it man), but unfortunately my mouse isn't recognised as problematic. I then tried to edit the main.c in order to include my usb vendor product id of the receiver as recognised in case this works. I made it, but unfortunately it doesn't continue as the device doesn't return known states to the program. My vendor id is Microsoft 045E and product id 00F9 . WIl you be able to include my mouse in your program please? It could help me a lot since the pc is in an akward place and it takes some effort to unplug the cable every time I previously booted in Windows ;-). Thank you very much

I paste here the output:

Mouse detected that might not be in X.org compatible mode. Making sure device is in compatibility mode...
Vendor Id: 045E Product Id: 00F9 Release: 2
Bus: 2 Device Number: 2
Vendor Name: Microsoft
Model Name: Microsoft Wireless Desktop Receiver 3.1
Could not determine what mode mouse is in. Leaving mouse alone.
Pipe error in communication with mouse.
libusb returned: -9

Just an other comment, I also modified the script so that when it finds my device to call the libusb_reset_device on it. The receiver's lights go on and off but unfortunately without a change. Scroll speed is not affected

Hi Dimitris,

I'm hoping I fixed the pipe error. The way I was talking to the mouse wasn't 100% accurate with the way normal HID devices work. I think I have fixed that so try the latest release.

http://sourceforge.net/projects/resetmsmice/files/resetmsmice-1.0.0.tar.gz/download

If you have a Microsoft Mouse you can look at the report descriptor for your device. It is in:

/sys/kernel/debug/hid

You will see a number of directories, only one or two will correspond to your vendor and product id, which you can get from the 'lsusb' command. In each of these directories is a rdesc file, which is the report descriptors for your device. If you see the following in one of these files, there's a good chance my program will work. In my next release of this program, it will not care what product id your device is, it will just check to see: 1) Your using a microsoft device 2) it's a HID device 3) It's a mouse 4) It has the following feature in its report descriptors:

  FEATURE(23)[FEATURE]
    Field(0)
      Logical(GenericDesktop.Mouse)
      Application(Consumer.0001)
      Usage(2)
        ff00.ff06
        ff00.ff0f
      Logical Minimum(0)
      Logical Maximum(1)
      Physical Minimum(1)
      Physical Maximum(16)
      Report Size(2)
      Report Count(2)
      Report Offset(0)
      Flags( Variable Absolute )
    Field(1)
      Logical(GenericDesktop.Mouse)
      Application(Consumer.0001)
      Usage(1)
        ff00.ff04
      Logical Minimum(0)
      Logical Maximum(1)
      Report Size(1)
      Report Count(1)
      Report Offset(4)
      Flags( Variable Absolute )

Hi Paul,
Thank you for your time in doing this. I tried the new version, but unfortunately it doesn't work. At first it didn't even detect my mouse again. I looked in your main.c file and found out that you forgot to update the KNOWN_MICE_IDS from 2 to 4. Once I made this change, it detected my mouse, but it didn't continue like the other time. Here is the output:

Checking for X.org compatibility mode on all Microsoft usb mice plugged into the system...
Mouse detected that might not be in X.org compatible mode. Making sure device is in compatibility mode...
Vendor Id: 045E Product Id: 00F9 Release: 2
Bus: 2 Device Number: 2
Vendor Name: Microsoft
Failed to open usb device.

UPDATE:::: Paul's newest version 1.0.2 from sourceforge works perfectly on my Wireless Optical mouse 2.0A (from wireless desktop set 3000)!!!! Congratulations to Paul for his work. Finally probably working mouse wheel as we want it. Thanks!

It it marvelous to hear that. Is there any chance that this fix will be included in the upstream?

I am happy to Quote Paul F Richards (paulrichards321) from Bug #971321

I worked my way up to version 1.0.4 a few months ago and have received positive feedback from multiple people. It works for the following mice:

* Microsoft Wireless Mobile Mouse 3500
* Microsoft Wireless Mouse 5000
* Microsoft Wireless Optical Desktop 3000
* Microsoft Comfort Mouse 4500
* Microsoft Wireless Mouse 1000

It most likely works for other mice as well. Let me know if it works for yours.

The source code, and the Ubuntu binary packages for release 12.04 (Precise Pangolin) for i386 and amd64 are here.

https://sourceforge.net/projects/resetmsmice/files/

You can also get the source code or binary ubuntu packages here:

https://launchpad.net/resetmsmice/+download
summary: - Several Models of Microsoft Wireless Mice, i.e. model Wireless Mobile
- Mouse 3500, 5000, and Wireless Laser Mouse 6000 have vertical scroll
- wheel issues in linux
+ Several Models of Microsoft Wireless and Wired Mice, i.e. models:
+ Wireless Mobile Mouse 3500, Wireless Mouse 5000, Wireless Optical
+ Desktop 3000, Comfort Mouse 4500, Wireless Mouse 1000 among others have
+ erratic vertical scroll wheel issues in linux after dual booting in
+ Microsoft Windows

Please let me know if you have any issues. paulrichards321 _at_ gmail.com