I was seeing many events with: xev | grep -B 2 "button 4" Interestingly, on the bad mouse I found I was getting occasional "button 4" events, even when I was scrolling up. 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. So the battery has nothing to do with the problem. I then tried measuring the battery voltage in the mouse to check if it could have been the signal. So, I then tried another mouse (identical to the first) and that worked perfectly. 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. It was odd that one mouse was worse than the other. Which reliably outputs two events everytime I scroll up one notch.īuttonPress event, serial 37, synthetic NO, window 0x7000001, My up wheel is Button 5 so: xev | grep -B 2 "button 5" I tried another generic USB wireless mouse (from a different manufacturer) and the problem was even worse. Sometimes I'd scroll down and the screen would jump up. In this mode the driver will discriminate opposite direction from the last one, lets say, in a ring buffer with five last elements.
Write a mode in the driver in which it will turn into when detecting fast changes between back and forth at the mouse wheel.
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.
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. I know the inner workings of an electronic mouse and it support such an explanation. I suggest that the hardware inside the mouse is not good enough to distinguish between back and forth and fast faster fast faster. 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've got a wild guess what's the problem.įirst off, this is a wheel with discrete positions on the wheel. In Windows, it works perfect without a driver. 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. When scrolling the wheel very very slowly, it works okay, exactly five lines at the time in gedit.
0 kommentar(er)
