Bug 2927

I think the whole mouse acceleration thing should be redone. I think it is
impossible to turn of acceleration completely, I'm not sure, but I think it
is... I'm having troubles finding it in the xorg codebase thoguh ... :/

Also ref bug 138 and bug 4490 . 

everyone thinks they can do mouse acceleration better, and everyone always gets
it wrong.  we've gone through about three acceleration algorithms since 6.7 and
there's no indication anyone prefers one over the other.

this sort of request really needs to be accompanied by patches because otherwise
the interpretation is totally up to whoever ends up implementing it.

*** Bug 4490 has been marked as a duplicate of this bug. ***

ajax:  note that this is not about acceleration.  This bug is not INVALID.     
     
Jeff's request was for a way to set the *speed* of the mouse.  This is    
currently not available.    
 
This is not a duplicate of 138 or 4490.  
   
It was possible to set the Resolution on some PS/2 mice.  This does not work    
on most USB mice and with the newer 800dpi mice the speed is stuck at 2x.  It    
appears that this could be tweaked in the kernel as a compilation option but    
that is a long way from a runtime adjustment.    
    
I'll say this again in a few ways to make it perfectly clear:    
    
  * acceleration is not speed    
  * speed could also be called "scale" or "resolution"    
  * speed is the ratio between how far I move the mouse    
    and how far the pointer moves    
  * this cannot be changed with xset    
  * this has absolutely nothing to do with how fast the mouse moves   
  
--Eric Wilhelm <ewilhelm at cpan dot org>   

(In reply to comment #5)
> ajax:  note that this is not about acceleration.  This bug is not INVALID.     

No, it is about acceleration.  The feature you're describing is a linear scaling
from 1 unit of mouse movement to N units of pixel movement, and that by itself
is broken.  You _have_ to have the ability to move by exactly one pixel.

So any implementation of scaling has to be done simultaneously with modifying
the acceleration code.  Which we have done, time and again, and no one has ever
come up with any measurable improvement.

> The feature you're describing is a linear scaling   
> from 1 unit of mouse movement to N units of pixel movement   
   
Actually, I want a linear scaling of N units of mouse to 1 unit of pixel.  This   
is what is actually missing.   
   
The OP wants his mouse faster -- ok, that is a physical limitation of the   
resolution of his mouse hardware.  
  
I have a high-res mouse and want to slow it down.  I need to be able to make  
large movements with the mouse and prevent it from bouncing around with very  
small movements.  
   
> So any implementation of scaling has to be done simultaneously  
> with modifying the acceleration code.  
  
Only with scaling *faster*, since as you pointed out:  you have to be able to  
move by only one pixel.  Sorry I had missed that bit.  I'm happy to submit a 
separate "RFE: must be able to slow mouse down" or we can just change this one. 
 
Thanks, 
Eric 

Hi!

I have this same problem wiht my Logitech LX7. Mouse (poitter) is moving way to
fast rendering it unusable. 

I upgraded my mouse from Logitech MouseMan wheel Optical to Logitech LX7. Now
poiter is about 3 times faster than before. I can use xset m to tone it down but
then it would be trade of with speed and accuracy. 

If I use "xset m 1/3 1" there is no acceleration only accurate and slow constant
speed. This was my old mouse's normal speed.

Other way around I can use "xset m 1 1" and the speed would be like my old
mouse's accelerated speed (with out accuracy).

My soulution to this would be new function (speed-multiplier, acceleration,
treshold)
xset m <speed-multiplier> <acceleration> <treshold>
"xset m 1/3 1 15" would make my new mouse act like old one.

[Or if speed-multiplier is used as a default speed to acceleration and treshold
my line would be: "xset m 1/3 5/2 5 (which might be bad since altering
speed-multiplier affects all other setting to)]

I have filled this bug-report to Ubuntu:
https://launchpad.net/distros/ubuntu/+source/xorg/+bug/51552

Hi,

I have filed bug#8583, a patch which should solve the discussed problems.
Comment encouraged.

--
Simon

As reported in bug 3885 the documentation of xset does not mention
a hidden feature avaliable since XFree86 in which a 0 in one
of the mouse settings makes the system use a "slow motion gives
precisse pointer, fast gives big screen jumps" system. For example
I have a machine with "xset m 7/4 0" and it has a really nice mouse
handling.

Did that code get removed? I have to test newer Xorg, but I think
it was there after the transition from XF86.

After some investigation, I think I found code that does something
when threshold is 0. It starts at line 955 in
http://webcvs.freedesktop.org/xorg/xserver/xorg/hw/xfree86/common/xf86Xinput.c?view=annotate
The other part of the if looks pretty much what everyone
complains about two speed mouse.

Also found a really old mail that seems to look similar to
the above code. Maybe the changes mentioned by ajax are the
differences, tho the annotate says it is rather and untouched
code.
http://marc.theaimsgroup.com/?l=xfree-xpert&m=101624642005523&w=2

I also just got the machine upgraded to 7.1.1 and it feels (no long testing
so excuse me if it is my imagination) that the system works, precise for
small movements, and side to side jump with a fast wrist shake. Is
the above code not used for the mouse and I am seeing something
else doing the acceleration?

For all the people trying with xset m A/B N and similar, could you test
xset m A/B 0? Thanks.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Created attachment 9682 [details] [review]
Patch implementing a mouse speed setting on a per-mouse basis

As an owner of a high resolution bluetooth mouse I was very disappointed that 
I could barely use this mouse with my laptop since its speed was much too 
fast. The Option "Resolution" setting in the xorg.conf had no effect and 
setting a constand decelleration via xset was no option since that would 
render my touchpad unusable.

Since the big google did not find any solution, and since the original code 
was open source and understandably written, I decided to take the matter 
into my own hands and wrote the following patch to add  a per-pointing-device 
option to the xorg.conf that allowed me to change my mouse's sensitivity by 
an arbitrary factor independently from my touchpad response.
The line
  Option       "Sensitivity" ".5"
in the Section "InputDevice" for my mouse now solves all my problems and might 
be of interest for others too.  

Although I can't really think about any use for real values >1, it is still 
possible. However this might make it impossible to point the mouse at certain 
pixels so use it with care.

So please enjoy and let me hear about your opinions about this!

Closing - see Bug 8583. The new pointer accel code should provide enough options to tweak it to your preference (even on a per-device basis).