Strange scroll wheel behavior

You too ...

I had been chasing this fault in Debian on a desktop, where scrolling the mousewheel upwards in a webpage sends the browser back to a previous page, rather than to the top of the page!

It was driving me mad, so investigated with xev.

==========

My xev output,

adrian@desktop:~$ xev

ButtonPress event, serial 34, synthetic NO, window 0x4c00001, root 0x1cb, subw 0x4c00002, time 19590480, (42,57), root:(1032,373), state 0x0, button 8, same_screen YES

ButtonPress event, serial 34, synthetic NO, window 0x4c00001, root 0x1cb, subw 0x4c00002, time 19590480, (42,57), root:(1032,373), state 0x0, button 9, same_screen YES

Button 8/9 is normally for forward/backwards "horizontal" scrolling.

Bug 443284 - mousewheel generating bogus button events

has a workaround.

Supply voltage drop perhaps.

-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. |

I had the same problem recently with a Logitech M105 mouse: scroll wheel was erratic, but clickers and optical tracking were fine. The problem turned out to be a mouse full of hair and dust that interfered with the optical sensors on the scroll wheel. Taking it apart, there's one screw that holds the Logitech together, cleaning out the collected gunge inside it and reassembly fixed it completely.

I've had consistently good experiences with the Logitech mice: its been my goto brand fir at least a decade. Or, there are plenty of that model mo56uo Dell mice on eBay for around $US 8

After reading the replies to this thread I decided to try putting the USB cable for the mouse back into the hub port on the keyboard. It was meant to be a null experiment, replicating the original problem.

To my utter surprise, the mouse scrollwheel seems to work perfectly. It looks as if the solution was merely to re-seat the connector. Evidently it was some sort of bad connection, much to my astonishment.

Thanks to all for reading and replying!

bob prohaska

Blind guess based on experience. Faulty hardware is often pattern sensitive...

...example if you have hardware that commonly sets a bit high, no data in which that bit is already high will notice...

I had a really nasty bug to trace years ago - program transfer from floppy to hard drive was being corrupted. But only when a video capture card was installed...turned out that a unique combination of address and I/O (this on an *86 hardware platform with I/O instructions) coupled with a terrible piece of hardware design - massive propagation delays in the decoder - meant that if you happened to have the lower order bytes of the address on te bus correspond to the video card, and then changed them and raised an IO request for data from the floppy, the card would still think it was 'selected' and would grab the IO bus. And stuck a couple of FFHs on the data stream.

We wrote to the manufacturer of the card showing them detailed timing calculations as to why it was a POS. They replied that no one else had complained and it was nothing wrong

People think hardware works, or it doesn't., In reality it can go very flaky - low voltage, marginal timing, temperature stability issues.

Code works or it doesn't yes - apart from issues with asynchronous interrupts etc. Take off a coder hat and put on an analogue hardware hat and its perfectly possible to see why stuff can work most of the time but crash some of the time.

This has a strong smell of a mouse cranky with supply voltage, or maybe a marginal cable. I'd get a powered USB hub, connect that to the keyboard outlet and connect the mouse to the hub. If everything works OK, just ditch the mouse and get a good one.

Probably oxidation on the connector. Either or both. Plug it in and out dozen times. That should "clean" it a bit.