7

I am using Debian 6.0.4. The mouse wheel scrolls way to much for it to be any use. Is there any way to configure how much "scrolling" is done with with one mouse wheel turn?

Update:

My keyboard and mouse are wireless, connected to a USB port in a KVM which is connected by USB to the computer (and it even works).

xinput --list output:

⎡Virtual core pointer                       id=2    [master pointer  (3)]
⎜↳ Virtual core XTEST pointer               id=4    [slave  pointer  (2)]
⎜↳ Microsoft Microsoft® 2.4GHz Transceiver v8.0 id=9    [slave  pointer  (2)]
⎜↳ Microsoft Microsoft® 2.4GHz Transceiver v8.0 id=10   [slave  pointer  (2)]
⎜↳ Justcom Technology USB KVM Switch        id=12   [slave  pointer  (2)]
⎣Virtual core keyboard                      id=3    [master keyboard (2)]
↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
↳ Power Button                              id=6    [slave  keyboard (3)]
↳ Power Button                              id=7    [slave  keyboard (3)] 
↳ Microsoft Microsoft® 2.4GHz Transceiver v8.0  id=8    [slave  keyboard (3)]
↳ Justcom Technology USB KVM Switch         id=11   [slave  keyboard (3)]

xinput --list-props 9 output:

Device 'Microsoft Microsoft® 2.4GHz Transceiver v8.0':
    Device Enabled (128):   1
    Device Accel Profile (254): 0
    Device Accel Constant Deceleration (255):   1.000000
    Device Accel Adaptive Deceleration (257):   1.000000
    Device Accel Velocity Scaling (258):    10.000000
    Evdev Reopen Attempts (246):    10
    Evdev Axis Inversion (259): 0, 0
    Evdev Axes Swap (261):  0
    Axis Labels (262):  "Rel X" (136), "Rel Y" (137), "Rel Misc" (263)
    Button Labels (264):    "Button Left" (129), "Button Middle" (130), "Button Right" (131), "Button Wheel Up" (132), "Button Wheel Down" (133), "Button Horiz Wheel Left" (134), "Button Horiz Wheel Right" (135), "Button Side" (249), "Button Extra" (250), "Button Unknown" (247), "Button Unknown" (247), "Button Unknown" (247), "Button Unknown" (247)
    Evdev Middle Button Emulation (265):    2
    Evdev Middle Button Timeout (266):  50
    Evdev Wheel Emulation (267):    0
    Evdev Wheel Emulation Axes (268):   0, 0, 4, 5
    Evdev Wheel Emulation Inertia (269):    10
    Evdev Wheel Emulation Timeout (270):    200 
    Evdev Wheel Emulation Button (271): 4
    Evdev Drag Lock Buttons (272):  0
2

For the following to work, you need programs xte and xbindkeys. For Debian, and most derivatives like Ubuntu, these come in packages xautomation and xbindkeys respectively. Should you use some other distribution, you'll have to just search your package manager to find the correct packages.

The idea behind that follows is that instead of actually accelerating movement of the mouse wheel, we generate multiple button events each time the wheel is scrolled. The way this is done does not save your cpu, as an external program will be run every time we generate multiple button events ie. every time the scroll wheel is rolled. This may be of some consideration, but a hack is a hack.

First you need to get the id of the input device, ie. the mouse, you are using. You'll get this from output of xinput list.

Then you need to get the button map for the device. You'll get this from output of xinput get-button-map <device>.

To find out which buttons map to the scroll wheel, run xinput test <device> and scroll up/down a few times. That will output events from the device specified to the terminal and lets you see which buttons map to the scroll wheel.

For the sake of an example, we'll be using an old Microsoft USB mouse, having two normal buttons and a scroll wheel. Rolling the wheel up maps to button 4 and rolling the wheel down maps to button 5. Luckily the button map for this device has two unused buttons, 6 and 7, so we'll use these.

First we remap buttons 4 and 5 to unused buttons.

xinput set-button-map <devid> 1 2 3 6 7 4 5

This will let us use events for buttons 6 and 7 for wheel events, thus enabling us to do whatever we like when events for those buttons are received. In this case we are going to produce multiple mouse events for a single mouse wheel roll (ie. a click in either direction).

To multiply (accelerate) by three, for example, we'd put the following into ~/.xbindkeysrc:

"/usr/bin/xte 'mouseup 6' 'mouseclick 4' 'mouseclick 4' 'mouseclick 4' &"
b:6 
"/usr/bin/xte 'mouseup 7' 'mouseclick 5' 'mouseclick 5' 'mouseclick 5' &"
b:7 

That in effect binds to release event of button 6 three click events of button 4. Binding that directly to release event of button 4 would produce an infinite loop, because every time button 4 is released, three new events of the same type for the same button are generated. That is why we remapped the buttons earlier.

To test the setup, run xbindkeys -n -v (this will produce verbose output on the console, letting you see what exactly gets produced when you roll the wheel of your mouse. If everything goes fine, this should produce something like this:

user@host:~$ xbindkeys -n -v
displayName = :0
rc file = /home/sjl/.xbindkeysrc
rc guile file = /home/sjl/.xbindkeysrc.scm

min_keycode=8     max_keycode=255 (ie: know keycodes)
"/usr/bin/xte 'mouseup 6' 'mouseclick 4' 'mouseclick 4' 'mouseclick 4' &"
    m:0x0 + b:6   (mouse)
"/usr/bin/xte 'mouseup 7' 'mouseclick 5' 'mouseclick 5' 'mouseclick 5' &"
    m:0x0 + b:7   (mouse)
starting loop...
Button press !
e.xbutton.button=6
e.xbutton.state=0
"/usr/bin/xte 'mouseup 6' 'mouseclick 4' 'mouseclick 4' 'mouseclick 4' &"
    m:0x0 + b:6   (mouse)
got screen 0 for window ae
Start program with fork+exec call
Button release !
e.xbutton.button=6
e.xbutton.state=0
Button press !
e.xbutton.button=7
e.xbutton.state=0
"/usr/bin/xte 'mouseup 7' 'mouseclick 5' 'mouseclick 5' 'mouseclick 5' &"
    m:0x0 + b:7   (mouse)
got screen 0 for window ae
Start program with fork+exec call
Button release !
e.xbutton.button=7
e.xbutton.state=0

If you now move the focus to some scrollable window, Firefox for example, you should see that scrolling with the wheel has become three times as fast as it was.

Now all left to do is to start xbindkeys in the background when you start you X session. That is left as an exercise for the reader.

3
  • Thanks for the thorough explanation. I'll check it out if I install debian again.
    – vainolo
    Aug 11 '14 at 9:51
  • Please include your output from xinput get-button-map <device> so I can better understand how the button mapping works. That part is throwing me off right now, as I don't understand it. Jan 2 '18 at 18:42
  • Note: an alternate solution (which I think uses the process above in its implementation) is to use imwheel. More info here: askubuntu.com/a/304653/327339 and here: askubuntu.com/a/991680/327339 Jan 3 '18 at 2:33
1

You can control the acceleration of the mouse (and scroll wheel) through the commandline program xinput. Use xinput --list to list the input devices. You can then use the ID of your mouse to list its properties like xinput --list-props <ID>. There should be one for the scroll wheel acceleration. You can change it through xinput --set-prop <ID> <propertyID> <value>. You might have to experiment with the values a bit to figure out the right one.

8
  • 1
    Thanks for the answer. I found my input device (9) and did xinput test 9. Scrolling up one click on the wheel gives button press 4 16 times, scrolling down one click gives button press 5 16 times. But when I look at xinput list-props 9 there is entry with a value 16. I tried changing Wheel Emulation Inertia but nothing changed. There are no other parameters that seem to be of help (haven't tried others anyhow). Do I have to restart X for the changes to take place? Any other places where I can search?
    – vainolo
    Feb 1 '12 at 15:24
  • You don't need to restart X for the changes to take effect. Could you post the output of xinput --list and xinput --list-props 9 please? Feb 1 '12 at 18:02
  • I updated the question with the output
    – vainolo
    Feb 1 '12 at 18:54
  • 1
    Have you tried plugging the mouse in directly and not via the KVM switch? Feb 2 '12 at 18:20
  • 1
    Why didn't I try this before. Yes, the mouse now scrolls normally. And the funny thing is that I returned it to the KVM and it also works OK. running xinit list shows that now the KVM before the transceiver and not after it. Weird... But thanks anyway.
    – vainolo
    Feb 4 '12 at 22:29
1

My Microsoft Wireless Mouse 1000 has the "Evdev Scrolling Distance" property.

Try to increase to 3, 3, 3

xinput --set-prop 10 274 3, 3, 3
2
  • Might be good to mention that you got "10" from running the "xinput --list" command and looking for your device's ID and 274 from running "xinput list-props 10" and looking at the number next to Evdev Scrolling Distance.
    – smckee
    Dec 27 '16 at 22:25
  • I tried this on CentOS 7 w/ Cinnamon and it didn't work. The default values were 1, 1, 1, and setting it higher made it scroll LESS distance. I tried 0.1, 0.1, 0.1, and it accepted those values but it wasn't any faster. Seems 1, 1, 1 is fastest it gets but is only about 3 lines per wheel notch.
    – Rich
    Jan 27 '17 at 17:38
1

I notice you're using a Microsoft Microsoft® 2.4GHz Transceiver device. Many, many Linux users have encountered scrollwheel-related insanity with Microsoft pointing devices. Steps to solve the problem are almost always:

  1. Switch mouse off and then on again.
  2. If step 1 didn't work, unplug USB dongle and plug it back in again.

I know this sounds stupidly simple. I had the same issue. After hours of googling and probing my OS, it turned out scroll events were being duplicated because of a bad device/driver state.

I was revving myself up to start writing a middleware driver to sit between my kernel and my Xserver to solve the problem. (libevdev is the place to start if you're ever interested yourself.) But I decided the occasional switch toggle was sufficient.

0

Generally the mouse wheel resolution is determined by the desktop environment you use. Which desktop environment are you using currently?

4
  • I am using Gnome 2.30.2
    – vainolo
    Jan 30 '12 at 21:37
  • I'm a debian/KDE user for 5+ years and KDE always had it. In gnome it looks like an automatic speed calculator has been added in 2.40. I'm not sure whether the X.org drivers evdev or mouse have this functionality but, I can strongly recommend to moving to testing branch of debian if you're using it as a desktop or personal system and have no special resons to use debian stable.
    – bayindirh
    Jan 30 '12 at 21:57
  • Thanks... but how would that help?
    – vainolo
    Jan 31 '12 at 7:13
  • Debian testing is a rolling release, running nearly bleeding edge versions of the available software and it's as stable as other distributions. In short, it'll bring you a more modern distro with more features.
    – bayindirh
    Jan 31 '12 at 11:24
0

I found a solution to my specific device. It may be of help to others. Mouse: Logitech M560 on a unifying receiver.

$ xinput output:

 Virtual core pointer                       id=2    [master pointer  (3)]
   ↳ Virtual core XTEST pointer                 id=4    [slave  pointer  (2)]
   ↳ Logitech Unifying Device. Wireless PID:4002    id=9    [slave  pointer  (2)]
   ↳ Logitech Unifying Device. Wireless PID:402d    id=10   [slave  pointer  (2)]
...

my mouse is id 10 (and the keyboard is 9)

$ xinput list-props 10

Device 'Logitech Unifying Device. Wireless PID:402d':
Device Enabled (143):   1
Coordinate Transformation Matrix (145): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (269): 2
Device Accel Constant Deceleration (270):   3.000000
Device Accel Adaptive Deceleration (271):   1.000000
Device Accel Velocity Scaling (272):    10.000000
Device Product ID (263):    1133, 50475
Device Node (264):  "/dev/input/event2"
Evdev Axis Inversion (273): 0, 0
Evdev Axes Swap (275):  0
Axis Labels (276):  "Rel X" (153), "Rel Y" (154), "Rel Horiz Wheel" (268), "Rel Vert Wheel" (296)
Button Labels (277):    "Button Left" (146), "Button Middle" (147), "Button Right" (148), "Button Wheel Up" (149), "Button Wheel Down" (150), "Button Horiz Wheel Left" (151), "Button Horiz Wheel Right" (152), "Button Side" (291), "Button Extra" (292), "Button Forward" (293), "Button Back" (294), "Button Task" (295), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266)
Evdev Scrolling Distance (278): -4, 1, 1
Evdev Middle Button Emulation (279):    0
Evdev Middle Button Timeout (280):  50
Evdev Third Button Emulation (281): 0
Evdev Third Button Emulation Timeout (282): 1000
Evdev Third Button Emulation Button (283):  3
Evdev Third Button Emulation Threshold (284):   20
Evdev Wheel Emulation (285):    0
Evdev Wheel Emulation Axes (286):   0, 0, 4, 5
Evdev Wheel Emulation Inertia (287):    10
Evdev Wheel Emulation Timeout (288):    200
Evdev Wheel Emulation Button (289): 4
Evdev Drag Lock Buttons (290):  0

I think I got lucky with my driver to have an "Evdev Scrolling Distance (278)", and adjusted it as -4, 1, 1. (minus) is for inverting the wheel direction (interestingly the button inversion 4 5 -> 5 4 doesn't work in this case, but this setting does). The value defaults was 1, 1, 1. Experimenting showed that it got slower with bigger abs(number), hence value 4.

I installed the driver "solaar", maybe for reference here is the link Debian repository

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.