The only way I have found that works (and I have only tried on Ubuntu) is with the
First you have to identify the device number for the mouse you want to change:
# xinput list
â¡ Virtual core pointer id=2 [master pointer (3)]
â â³ Virtual core XTEST pointer id=4 [slave pointer (2)]
â â³ Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) id=10 [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)]
â³ CHICONY USB Keyboard id=8 [slave keyboard (3)]
â³ CHICONY USB Keyboard id=9 [slave keyboard (3)]
â³ IR-receiver inside an USB DVB receiver id=11 [slave keyboard (3)]
Now, in this example I will be playing with my Microsoft mouse. id=10
Now let's see what properties this device can handle:
# xinput list-props 10
Device 'Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)':
... cruft cut ...
Device Accel Profile (259): 3
... cruft cut ...
This value is how the driver handles the acceleration:
-1: none no velocity-dependent pointer acceleration or deceleration. If constant deceleration is also unused, motion processing is suppressed, saving some cycles.
0: classic (the default) similar to old behaviour, but more predictable. Selects between 'polynomial' and 'simple' based on threshold =/!= 0.
1: device-dependent available if the hardware driver installs it. May be coming for synaptics.
2: polynomial Scales polynomial: velocity serves as the coefficient, acceleration being the exponent. Very useable, the recommended profile.
3: smooth linear scales mostly linear, but with a smooth (non-linear) start.
4: simple Transitions between accelerated/unaccelerated, but with a smooth transition range. This has the fundamental problem of accelerating on two niveaus, on which acceleration stays independent of velocity. Traditionally the default however.
5: power accelerates by a power function. velocity is the exponent here. Adheres to threshold. Will easily get hard to control, so it is important you have properly tuned your velocity estimation.
6: linear just linear to velocity and acceleration. Simple and clean.
7: limited smoothly ascends to acceleration, maxing out at threshold, where it becomes flat (is limited).
So from that we can see that if we set this property to -1 it will disable acceleration completely.
$ xinput set-prop 10 259 -1
So now we have no acceleration, but is that what we want? The mouse is a bit slow now. Sadly that's how it is. With acceleration disabled you get a 1:1 relationship between the mouse and the display. You move the mouse left one dot and the mouse pointer moves one pixel left. If there were a way to multiply the input movement (say by 2) then every other pixel on each axis would be inacessible to the mouse. That would make accurate positioning of the mouse pretty difficult. The 'sensitivity' setting in some GUI mouse control panels actually does the opposite of what you would expect - the most sensitive is a 1:1 ratio - it's the acceleration which makes it seem so much faster.
So you want faster movement, but you don't want acceleration. The only way you can do that is in hardware. Basically, you will need to buy a more sensitive mouse. Look for one with a higher DPI (Dots Per Inch - yes, just like a printer). I find my old Microsoft IntelliEye is sensitive enough with acceleration disabled to be useable.
Or maybe your mouse is just too sensitive? Even with acceleration disabled it's too fast for your liking? Well, that's where the
Device Accel Constant Deceleration (260): 1.0000
setting comes in. This is a constant deceleration (or desinsitizing) ratio. By default it's 1:1 but will take any number (even fractions) above that. To get a slight slowdown of the mouse:
$ xinput set-prop 10 260 1.2
Or a massive slowdown for really delicate work:
$ xinput set-prop 10 260 10
Or return it to normal:
$ xinput set-prop 10 260 1
This works even when the acceleration profile is set to -1 (Disabled).