label of the mouse motion preferences is misleading

[xzero1]

The sensitivity slider (under System->preferences->mouse) seems to have no effect whatsoever. I have a Logitech MX620 (usb wireless) mouse. This symptom also occurs in Jaunty Beta as well as Ubuntu Intrepid.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
MachineType:

NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-11-generic 2.6.28-11.40
ProcCmdLine: root=UUID=dc8aba74-b7fa-4aa6-b633-c8ad7ad1d6ce ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-11.40-generic
SourcePackage: linux

[lspci]
00:00.0 Host bridge [0600]: nVidia Corporation nForce3 250Gb Host Bridge [10de:00e1] (rev a1)
     Subsystem: Giga-byte Technology Device [1458:0c11]
01:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce 7600 GT [10de:02e0] (rev a2)
     Subsystem: XFX Pine Group Inc. Device [1682:2249]

[Daniel Hollocher (chogydan)]

on intrepid for me, there is definitely something weird going on. The mouse sensitivity setting seems inverted (ie, set it to low, and the mouse moves fast; set it high, mouse moves slower).

[Andreas Moog (ampelbein)]

Reassigning to gnome-control-center. That is where this option has its home.

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?

 This will help us to find and resolve the problem.

[jon (jon-noflag)]

* Is this reproducible?

I dont know how you might reproduce it to be honest - other than that my toshiba satelite pro with jaunty has this bug, and similar machines might have the same problem.

I am using a work around at the moment - i use the "xset m" command to manually set the mouse speed. this needs to be set every time X is restarted.

[xzero1 (kdogn)]

In my case it is reproducible. On my system the bug is always there. As I understand it, xset m allows one to adjust the acceleration and threshold; whereas sensitivity should be the base ratio of mouse pointer dpi to mouse movement. Can the sensitivity be adjusted with xset? Could this be a driver issue?

[Pelládi Gábor (pelladigabor)]

This is always the case for me on an Asus EEE 901. Touchpad sensitivity is very slow, and the sensitivity slider (System->Preferences->Mouse) does nothing. The acceleration slider works, though, but it is not what I want.
Is there an other way to adjust sensitivity, as a workaround for this bug?

[Sebastien Bacher (seb128)]

does anybody get the issue using a mouse and not a touchpad?

[Stefan Berggren (nsg)]

> does anybody get the issue using a mouse and not a touchpad?

Yes, my workstation has that problem to. Jaunty, upgraded from Intrepid.
Sensitivity slider has no effect.
The default sensitivity with a mouse is acceptable so it isn't a huge problem.

A also have a Asus Eee and the problem is present there to, and with a touchpad the problem is annoying like hell. (Sensitivity is at acceptable levels if I connect a mouse).

[Pelládi Gábor (pelladigabor)]

I connected an USB mouse to my EEE 901, and mouse sensitivity didn't have any effect on the external mouse, either. But the mouse had a more acceptable speed, unlike the touchpad that makes me crazy. It takes about five finger moves from the left edge of the pad to the right egde, to be able to move the cursor across the 1024px wide screen.

[Sebastien Bacher (seb128)]

this code didn't change a lot recently and use xorg api that's rather an xorg issue

[Martin Olsson (mnemo)]

It would be useful if some people affected by this bug attached copies of their /var/log/Xorg.0.log files so we can see which input drivers are affected. Thanks.

Further, it's useful if someone could file a good upstream bug at bugs.freedesktop.org (file the bug against the right input driver) and then link the upstream bug to this bug using the "Also affects project" link just below the yellow strip at the top of this bug report. That way if upstream fixes we bug we get notified and we can package the bugfix for ubuntu. To get the bug fixed, it's important that the person who files the upstream bug answers any questions the upstream developers asks.

[Pelládi Gábor (pelladigabor)]

I tested this bug with a Jaunty live CD on my desktop computer. It has an USB mouse, but the mouse sensitivity setting is ignored like on my EEE. It is not so annoying, though, because the default value is acceptable.
Is there somebody for who this setting actually works?

[Pelládi Gábor (pelladigabor)]

I have searched for similar bugs, these might be connected to this bug:
https://bugs.launchpad.net/bugs/61561
https://bugs.launchpad.net/bugs/177146
https://bugs.launchpad.net/bugs/28052
https://bugs.launchpad.net/bugs/244051
These reports all say that the mouse sensitivity has no effect.

[Pelládi Gábor (pelladigabor)]

Now I have learned something. Sorry if I say trivial things for you, but I think it is not clear for everybody.
Mouse sensitivity has very little to do with the movement speed of the mouse or touchpad. That is controlled by acceleration. High acceleration means faster cursor movement.
To be able to move fast, and at the same time be precise, there are two levels of speed. The slower speed is active if you move the mouse or touchpad less than the value in pixels specified by sensitivity. This speed is always 1, it cannot be adjusted.
If you move more pixels than sensitivity, then the mouse will move faster, as fast as your acceleration setting is.
But high acceleration makes the cursor "jumpy". So you either have a slow cursor, or a jumpy cursor.

So far the effects of the options in gnome-control-center. I can see the following issues:
1. The label of the "sensitivity" slider is misleading. I thought it should affect the speed of the cursor. "Threshold" would be better IMHO, as this option is called in man xset. After I have read the comments here, this is the main problem, so this bug should focus on the misleading option name in gnome-control-center.
2. There is a feature in newer xservers, that enables continuous pointer acceleration. You can try it with the command "xset m 2 0". This is much better than the two-level acceleration, but gnome-control-center does not provide a way to turn it on. It would be a nice feature.
3. The initial values after a fresh install are either too slow or too high for certain input devices, e.g. the touchpad of the Asus EEE 901. Better defaults are welcome, but it is less problem if it can be changed in gnome-control-center intuitively.

[Sebastien Bacher (seb128)]

there is already some upstream bugs about those issues, see http://bugzilla.gnome.org/show_bug.cgi?id=93445 and http://bugzilla.gnome.org/show_bug.cgi?id=152281

[Andrew P. (japoth)]

This problem is evidently still there in Lucid Lynx 10.04 LTS (i386 Desktop). I'm using an Itac Systems, Inc. Mouse-Trak trackball on th PS/2 mouse port, and as-shipped in the LiveCD, it takes multiple spins of the trackball to move the pointer from the left edge of the screen to the right edge. This trackball has its own built-in acceleration control that can be switched on and off with a button, and even with acceleration active it takes multiple spins to traverse the screen. When operating normally, a single spin of the ball is all it takes without acceleration; with acceleration a quick 20-40 degree rotation of the ball does it. (The Itac Mouse-Trak is an industrial trackball with a large, billiard-ball-sized phenolic ball mounted on precision plated steel shafts and ball bearings. When flicked with a fingertip, the ball will continue to spin for a second or so, unlike some cheap trackballs from Logitech, et al, using tiny, marble-sized plastic balls on simple friction bearings.)

When I move the mouse sensitivity control to "Low", it starts to behave more normally. When I move the sensitivity control to "High", the pointer becomes a slug.

Conclusion: The mouse sensitivity control sense is most definitely inverted. If it is running over a 0-255 range, as many 8-bit controls do, there may be an inadvertent subtraction or overflow occurring in the settings algorithm.

The mouse acceleration control sense appears to work correctly.

[fig_wright (fig-wright)]

I have this problem. The "sensitivity" slider does nothing on a laptop and a PC.

[redtela (redtela)]

I've had this problem since using a USB mouse with my touchpad. The mouse, it seems, is irrelevant (mine is an ageing Dell with no features other than 2 buttons & a click-able scroll wheel). The computer in use for this is a Samsung NC10, latest stable Ubuntu 10.10 - kernel updates were only downloaded yesterday.

$ uname -a
Linux NC10 2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 10:18:49 UTC 2010 i686 GNU/Linux

Given Pelládi Gábor's detail above, I had a play with the sliders in Preferences > Mouse...

The USB mouse does indeed seem to be inverted in the application of the sliders. Setting acceleration high and sensitivity low sets the mouse as I want - ie, it's responsive yet accurate - scrolling across 1200 pixels on screen takes about 2 inches of mouse movement. Perfect for me. The touchpad also responds sensibly (it's a small touchpad, moving the mouse around screen quickly & accurately is fairly tricky).

Personally, I blame the MS implementation of mouse sensitivity settings being wrong. Again, given Pelládi Gábor's explanation of how the settings SHOULD be applied, that makes sense (from a developer viewpoint). To me, and in my very limited use, the implementation within Linux has no bugs (I also use Windows as an OS daily, but I'm content just knowing the different implementations). However, others may not be so forgiving.

[donquixote (lemon-head-bw)]

Sensitivity min, Acceleration max -> I am happy.
Thanks a lot, Pelládi Gábor (#16).

And yes, the options and their labeling are awkward.

This is how I think about it. There are different levels to approach this.
1) There is a factor between physical mouse movement (in centimeters) and cursor movement (in px). That's the most naive model, and I think it is almost never that easy.
2) There is a function from physical movement speed and cursor speed. In an ideal world, this function should be continuous. A curve. The shape of the curve can be controlled by different parameters. Such as, acceleration and speed. Or, in this case, acceleration and "threshold" (what they call "sensitivity"). "Physical movement speed" is a value calculated from the last two or more mouse positions (*). Obviously, (1) is just a special case of (2).
3) Looking at the mouse movement trail in the last x milliseconds, we decide how to move the mouse cursor. Obviously (2) is a special case of (3), and probably we want exactly that.

(*) How do we measure "physical movement speed" ?
I imagine, what we start with is raw data points sent by the mouse. Different mice send this data with different frequency and resolution.
At first thought, we would say that mouse speed can be measured by comparing two subsequent data points, and their distance in pixel.
But wait.. what if the raw data gives us 10 data points of silence, and then one sudden jump of 8px? Then again 6 ticks with no movement, and then another 8px sudden movement? All of this because the reporting speed and accuracy is much higher than the actual sensor speed and accuracy. No idea if this is what actually happens, but can very well imagine.
In this case we need to look at more than just the latest two data points, to get a reasonable guess about movement speed.

Usually, the OS has some built-in curve based on customizable parameters. Or maybe even more than that, a secret algorithm looking at more than just the current movement speed.

Now, would it not be sweet to have an API for custom mouse acceleration functions? This would be a nice playing ground..
Such an API should expose either the estimated movement speed (2), or even the raw data sent by the mouse (3), and the implementing software would return an acceleration factor, or a movement vector.
Then some students could spend their usability lessons, to code us a mouse acceleration suite :)

[Sebastien Bacher (seb128)]

the issue has been fixed upstream