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
AReddy
  • 3,122
  • 5
  • 35
  • 75
vainolo
  • 191
  • 1
  • 1
  • 5

6 Answers6

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.

  • Thanks for the thorough explanation. I'll check it out if I install debian again. – vainolo Aug 11 '14 at 09:51
  • Please include your output from `xinput get-button-map ` so I can better understand how the button mapping works. That part is throwing me off right now, as I don't understand it. – Gabriel Staples Jan 02 '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: https://askubuntu.com/a/304653/327339 and here: https://askubuntu.com/a/991680/327339 – Gabriel Staples Jan 03 '18 at 02:33
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.

kdbanman
  • 154
  • 1
  • 8
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
Mura
  • 21
  • 1
  • 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

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.

Lars Kotthoff
  • 1,204
  • 11
  • 11
  • 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 01 '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? – Lars Kotthoff Feb 01 '12 at 18:02
  • I updated the question with the output – vainolo Feb 01 '12 at 18:54
  • Hmm, looks like for some people unplugging the mouse and plugging it in again worked. You could also try the same with the KVM switch. – Lars Kotthoff Feb 01 '12 at 19:08
  • Nothing happened :-( – vainolo Feb 02 '12 at 07:03
  • Hmm, maybe there's something that works for you [here](https://answers.launchpad.net/ubuntu/+question/9200)? – Lars Kotthoff Feb 02 '12 at 08:49
  • 1
    Have you tried plugging the mouse in directly and not via the KVM switch? – Lars Kotthoff Feb 02 '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 04 '12 at 22:29
0

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

bayindirh
  • 949
  • 1
  • 8
  • 19
  • 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 07: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

AReddy
  • 3,122
  • 5
  • 35
  • 75
AlbusMPiroglu
  • 111
  • 4