Improve mouse sensitivity and acceleration settings

[Trouilliez vincent]

In the mouse preferences dialog, I can adjust the "acceleration" just fine, but
the "sensitivity" has no effet whatsoever.
Whether I set it all to minimum or maximum, doesn't make teh slightest difference.
I use a generic PS/2 mouse.

[Sebastien Bacher (seb128)]

Thanks for your bug. The GNOME capplet just does

"set_motion_threshold (gint motion_threshold)
{
  XChangePointerControl (GDK_DISPLAY (), False, True,
                         0, 0, motion_threshold);
}
"

and the motion_threshold gconf key is updated correctly from the capplet

Reassigning to xorg

[Matt Zimmerman (mdz)]

Doesn't make any difference here either.

Sebastien, shouldn't it be checking the return code from XChangePointerControl?

[Sebastien Bacher (seb128)]

Matt, the manpage is not really clear about that, what is the return code for? A "BadValue" error would probably be noticed (g-s-d tends to no like them and they would probably listed by the log)

[Henrik Nilsen Omma (henrik)]

I can confirm that the Sensitivity adjustment causes no noticeable change in the pointer motion. The expected behaviour would be that a lower sensitivity would make it move more slowly (which is before the acceleration factor is applied).

Another useful interpretation would be that a low sensitivity would define a number of pixels that the pointer would need to move before the acceleration was applied OR a number of units the mouse was moved before the pointer moved at all. These two later interpretations would be good accessibility features because it would make it easier for people with unsteady hands to use the mouse (many elderly people). Really, I think all these settings should be configurable, but that might belong to some future mouse calibration dialog.

For now, I think we should either make sure that the slider alters the pointer speed or simply remove it completely.

[Fabio Massimo Di Nitto (fabbione)]

Makefile for the proof of concept

[Fabio Massimo Di Nitto (fabbione)]

code for the prrof of concept

[Fabio Massimo Di Nitto (fabbione)]

Ok I attached a proof of concept to show that xorg (libx11 and xserver) are doing the right thing.

How to use it:

edit the main.c file and replace XXXXXXXX first with 1
build and run
that will set the minimum threshold before the mouse is accelerated.

move the mouse in one corner of the screen and measure how much mouse movement you need to do to reach the other side of the screen.

change the value again to something absurd like 2000, that means start accelerating after 2000 pixels.

Repeat the above, and measure again.

In my test i need at least 5 times more mouse movement to reach the other side of the screen and the mouse move very slowly.

As you can see the value is changed correctly by both control-center and this program. That means that the comunication between all components happen properly, but the values that control-center is setting are too low to notice the difference (at least in my specific case).

Fabio

[Sebastien Bacher (seb128)]

Right, it works fine on my box too, the range is just maybe too limited. Vincent, you can try by putting the acceleration to the maximum and changing the sensitivity now, you should notice a difference, could you confirm that?

[Trouilliez vincent (vincent-trouilliez-modulonet)]

Okay I spent some time fiddling with all that, and taking notes so I can report accurately. Here it is:

With the "Acceleration" control left alone, in it normal/current position (about half way), then Fabio's program doesn't make any difference whatever the setting, 1 or 2000, it's completely ineffective.

Now if I do as Seb suggested, and turn the Acceleration slider all the way to the max, then the "Sensitivity" control now has some effect, but Fabio's program still has no effect though.

Here is the result:

1) "Sensitivity" control set to MIN : actual sensitivity : VERY high (unusable), Acceleration: impossible to asssess as a consequence.

2) "Sensitivity" control set to MAX: actual sensitivity : "normal"/usable. Acceleration: sudden, and extremely high.

[Fabio Massimo Di Nitto (fabbione)]

This just confirm that the X part of it works. The real problem is the range of values that control-center allows to set.

Fabio

[Trouilliez vincent (vincent-trouilliez-modulonet)]

I don't care about this bug anymore, and since nobody else does (no other subscribers, no duplicate), please feel free to reject/close it.

[Sebastien Bacher (seb128)]

That's sort of the same topic as http://bugzilla.gnome.org/show_bug.cgi?id=93445 upstream

[Simon-thum (simon-thum)]

This is not a bug peport but a patch proposal for enhanced mouse acceleration.
It 'fixes' bugs 2927, 3908 and related issues, as well as giving a more natural
feel for the mouse IMHO. I write 'fixes' in parentheses since it is not a
magical sword, but might need some settings.

It would be nice if a more experienced dev could help me crush the TODOs!
BTW, I use it and its rock stable.

Attached are documentation and patch.

[Simon-thum (simon-thum)]

Created an attachment (id=7319)
Documentation for the patch

[Simon-thum (simon-thum)]

Created an attachment (id=7322)
Patch for mouse speed/acceleration

[Simon-thum (simon-thum)]

Created an attachment (id=7492)
updated documentation

[Simon-thum (simon-thum)]

Created an attachment (id=7493)
patch for enhanced mouse acceleration

Some code cleanup, removed c++-comments, some optimization

[Daniel Stone (daniels)]

hi,
the algorithms and implementation look pretty good to me at a first glance.
could you please redo this against master, though? dix/getevents.c is what you
want to be looking at: GetPointerEvents will call acceleratePointer if
POINTER_ACCELERATE is set in flags. so what you want to be doing is storing all
your information in the ValuatorClassRec (include/inputstr.h), and then changing
which acceleration function you call.

also, please wrap your lines at 80 characters.

thanks!

[Simon-thum (simon-thum)]

Raising the code to dix is entirely possible but i order to get configuration
done I will have to extend the dix interface (export functions and a struct). If
this is not a good idea please write soon.

[Daniel Stone (daniels)]

that's fine. i suggest you just add an acceleration type integer to
ValuatorClassRec, and then a void *accelData or so, that the acceleration method
of your choice can use. that way, we only ever need to break abi once.

thanks!

[Simon-thum (simon-thum)]

Created an attachment (id=7772)
Patch for enhanced acceleration

The code is now in dix, but needs to be enabled for every server, which is
exemplary in hw/xfree86.
However, I have not yet managed to build Xorg, so the whole thing is untested
and might not even compile. Could someone (Daniel?) please apply it and give me
some feedback?

[Simon-thum (simon-thum)]

Created an attachment (id=7773)
Documentation for the patch

Documentation for the patch in general and configuration options

[Simon-thum (simon-thum)]

Just noted there is a small error:
This line:
https://bugs.freedesktop.org/attachment.cgi?id=7772&action=diff#a/dix/getevents.c_sec4
is superfluous and should not compile. Going to respost later.

[Simon-thum (simon-thum)]

Created an attachment (id=7858)
patch against master

I finally managed to get the code to dix so one can see the effects.
Sadly, there is a bug somewhere in the server that prevents (adaptive)
deceleration from working, which IMHO ist the most appealing feature.
Also, the integration is sort of a hack, but a more involved dev should easily
be able to improve that.

@Daniel: It seems that there is a Bug which shows up when you do e.g.
xset m 2 0
then slow movements are screwed. It seems that if the acceleration does not
accelerate but rather slow down strange things happen. You should not need to
apply my patch to reproduce.

[Simon-thum (simon-thum)]

Created an attachment (id=7859)
slightly revised doc.

[Simon-thum (simon-thum)]

I've been able to check my clain there is a bug in current git and it is (bug#9156).
simply do
>xset m 2 0
and see youself.
Since by default the proposed algo does not decelerate, it hides the problem, as
well as not using polynomial acceleration does.
I tried to fix but it seemingly depends on other factors. IMHO, the acc function
should be able to decelerate, but currently it's a mess.

[Simon-thum (simon-thum)]

Created an attachment (id=7969)
patch against master

This should now work and also fix the classic implementation.
Integration is still suboptimal, but it works fine.

[Simon-thum (simon-thum)]

Created an attachment (id=7970)
Documentation for the patch

[Bryan Hoyt (bryhoyt)]

Hi,

I hope this is a good place to leave this comment. I'm not a dev, but I'm very
interested in this patch.

I just want to say thank you very much to Simon for his work in implementing it.

I would encourage the developers to think seriously about including this in the
mainstream code as soon as possible; I've seen a fair bit of wishing on the web
(often among laptop users, because of their more restricted mouse requirements)
that X had a smoother mouse acceleration function.

[Simon-thum (simon-thum)]

Created an attachment (id=8201)
revised patch

This patch should again apply in current master branch.

[Simon-thum (simon-thum)]

I am still seeking feedback on this. Especially, I need hints on improving
integration in xfree86 backend:
1) how to suppress those carryover_ fields (see ApplyExtendedValuatorSettings)
2) should the dix api be changed to support the new valuator fields
3) where is a good place to apply the extended settings (or to call
ApplyExtendedValuatorSettings)? Must be after DEVICE_INIT (for valuators to
exist), and I'd like to stay device driver independent. Also, hotplug is an issue.

Thanks!

[Peter Hutterer (peter-hutterer)]

some cosmetics:
Use #defines for scheme names. Scheme 0 or 1 is not very explanatory.

Can you write one acceleratePointer and then split from there into accelPointerDumb, accelPointerSmart or whatever you want to name them? GPE shouldn't decide on the accel scheme and it'll make it more readable.

Don't call it carryover_accelScheme, don't be too apologetic. You might want to put scheme and data into a struct, it'll make it easier to add additional stuff at a later point in time.

please don't mix tabs and spaces. http://wiki.x.org/wiki/CodingStyle

xf86ProcessCommonOptions: bit hacky. don't strcmp, alloc memory inside PVC and call it dependent on option AccelerationScheme. PVC can then decide what to do.

[Simon-thum (simon-thum)]

Thanks for the comments!

Those carryover_ fields are in effect a hack I got rid of already. When it works (current Git won't on my machine even vanilla) youl'll see a post :)
I'll see what I can do about the rest.

[agd5f (agd5f)]

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

[Simon-thum (simon-thum)]

Created an attachment (id=9248)
Patch agains 1.2.0

This patch is against a 7.2 release / 1.2.0. It contains some improvements in config handling and velocity approximation.
The patch against git is not currently stable.

[Simon-thum (simon-thum)]

Created an attachment (id=9389)
patch against current git

This patch contains some of peters suggestions. I haven't introduced #defines but made up a function pointer to exchange schemes, so it can be implemented compile-time checked. Init/shutdown still needs improvement.

[Simon-thum (simon-thum)]

Created an attachment (id=9390)
documentation

Revised documentation

[Peter Hutterer (peter-hutterer)]

There's a load of needless whitespace diffs in that patch, seems your whitespacing differs to what the file already has. Makes it very hard to read. Apart from that it looks good from the little I know.

[Simon-thum (simon-thum)]

(In reply to comment #25)
> There's a load of needless whitespace diffs in that patch, seems your
> whitespacing differs to what the file already has. Makes it very hard to read.
> Apart from that it looks good from the little I know.
Got that one. In your previous post you said I shouldn't strcmp, but what am I supposed to do to match pointing devices?

[Daniel Stone (daniels)]

(In reply to comment #26)
> (In reply to comment #25)
> > There's a load of needless whitespace diffs in that patch, seems your
> > whitespacing differs to what the file already has. Makes it very hard to read.
> > Apart from that it looks good from the little I know.
> Got that one. In your previous post you said I shouldn't strcmp, but what am I
> supposed to do to match pointing devices?

if dev->valuator exists, then that's enough to set up acceleration.

the meat of the patch seems okay, but i have a few style issues with it (mainly adding two new headers and source files just for acceleration), so i'll clean it up and push it to an api-break branch this week.

[Simon-thum (simon-thum)]

Created an attachment (id=9565)
patch against master

this patch contains some minor improvements and works against current git.
The 2 headers are overkill, mainly a failed attempt to integrate the 1.2.0 and current git patch versions. IMHO putting ptraccel.h into input[str].h should be best, since that would preserve the fact you only need ptrveloc.h if you actually fiddle with it.
I have some improvements in queue[0], but apart from the small mem hole in CloseDevice() I don't know why it shouldn't be applied now.

[lordkenyon (g-vance)]

I'd like report the same issue with version 7.04

[Simon-thum (simon-thum)]

Created an attachment (id=10106)
revised patch against master

This version of the patch has some improvements:
 - it now has only one additional header
 - slow diagonal moves are measured more precise
 - no known memory leaks
 - improved structure so adding arbitrary acceleration functions should be easier to do in an ABI-compatible manner

[Simon-thum (simon-thum)]

Created an attachment (id=10107)
documentation

[Simon-thum (simon-thum)]

Created an attachment (id=10162)
patch against xorg-server 1.2.0

This patch contains an improvement backported from the git version so slow diagonal movements are handled better. It is also tested with multiple devices (mouse and synaptics).

[Simon-thum (simon-thum)]

Created an attachment (id=11617)
updated patch against current master

I've updated the patch to include profile selection, added a few acceleration profiles, and made the header structure more concise.

[Simon-thum (simon-thum)]

Created an attachment (id=11618)
updated documentation

updated documentation.

[Peter Hutterer (peter-hutterer)]

Can velocity data be freed through a callback function? Better than checking for the AccelSheme in CloseDevice.

I did not understand why xf86InitValuatorAxisStruct only applies the new settings if there are zero axis? typo?
It is better if you move this into InitValuatorAxisStruct, I guess xf86IVAS will die out over time.

aside from that, I like it. I haven't checked the actual algorithms for the acceleration though.

One thing: hotplugging should be covered with your code once you move to IVAS instead of xf86IVAS. I recommend trying this scheme with both the mouse and the evdev driver. These are the most common ones in use.

Cosmetics:
#include "ptrveloc.h" instead of #include <ptrveloc.h>
Indendation seems screwed in ApplySofteningAndConstantDeceleration, ClassicProfile
Please avoid // comments
For javadoc-like comments preceding each line with an asterisk makes the code easier to read (admittedly subjectively)
/**
 * foobar
 */

ptrveloc.h: can you move the comments to be next to the declarations instead of above? It's horrendous to read right now, especially w/o syntax highlighting.

[Simon-thum (simon-thum)]

(In reply to comment #34)
> Can velocity data be freed through a callback function? Better than checking
> for the AccelSheme in CloseDevice.
>
> I did not understand why xf86InitValuatorAxisStruct only applies the new
> settings if there are zero axis? typo?
> It is better if you move this into InitValuatorAxisStruct, I guess xf86IVAS
> will die out over time.
You've exactly hit the spots I consider suboptimal too :)
It's not a typo, but makes sure AEVS is called only once, as xf86IVAS is called once for each axis.
The reason I rely on all this is simply I need to evalute the config file, which makes that part viable only in xfree86 (AFAIK). I'm just not sure how to treat the issue such that I don't introduce more problems.
E.g. moving it in IVAS would make that fn take more parameters, and suddenly all its callers get involved. Any thoughts?

> aside from that, I like it. I haven't checked the actual algorithms for the
> acceleration though.
I don't feel like a math whiz, but I'm pretty sure they're fine :) Basically I think there should be some research but I don't know who would pay _that_.

> One thing: hotplugging should be covered with your code once you move to IVAS
> instead of xf86IVAS. I recommend trying this scheme with both the mouse and the
> evdev driver. These are the most common ones in use.
Regarding hotplug, I have not idea how to deal with config here. A XI DeviceControl API is some work, as I've seen.

> Cosmetics:
When it compiles again :)

[Peter Hutterer (peter-hutterer)]

(In reply to comment #35)
> It's not a typo, but makes sure AEVS is called only once, as xf86IVAS is called
> once for each axis.
> The reason I rely on all this is simply I need to evalute the config file,
> which makes that part viable only in xfree86 (AFAIK). I'm just not sure how to
> treat the issue such that I don't introduce more problems.
> E.g. moving it in IVAS would make that fn take more parameters, and suddenly
> all its callers get involved. Any thoughts?

two options:
- you modify all the callers. depends on when you want it to be in the server. there's more input ABI breakage down the road anyway.
- you create a second interface InitValuatorAxisStructWithAccel() and let IVAS call IVASWA with sane defaults. this is probably the better idea for now.

> Regarding hotplug, I have not idea how to deal with config here. A XI
> DeviceControl API is some work, as I've seen.

not as much as you'd think. we (well, daniels preferrably :) can probably knock something up in quite short time.

[Simon-thum (simon-thum)]

Created an attachment (id=11756)
preliminary patch

I chose option three: I applied your suggestion on cleanup in CloseDevice to init, and from the dix/ddx decoupling perspective I am quite satisfied now. The patch *DOES NOT WORK* but it shows how I intend to do it. However I need to modify ActivateDecice() or something like that. Are there any objections?

I've seen there was some cleanup in the DeviceControl handling, maybe I'll take a a second chance an that. If we head for 1.5, there should be some time left, right?

[Peter Hutterer (peter-hutterer)]

(In reply to comment #37)
> Created an attachment (id=11756) [details]
> preliminary patch
>
> I chose option three: I applied your suggestion on cleanup in CloseDevice to
> init, and from the dix/ddx decoupling perspective I am quite satisfied now. The
> patch *DOES NOT WORK* but it shows how I intend to do it. However I need to
> modify ActivateDecice() or something like that. Are there any objections?
>

had a look at it on the last plane, looks good. One thing is left, which is more style than anything again: can you put accel stuff into a struct?
so that in the end we get something like
  dev->valuator->accell.clean()
  dev->valuator->accell.init()
instead of
  dev->valuator->AccelCleanupProc
  dev->valuator->AccelInitProc

I think it makes the code more readable. aside from that, I like it.

[Simon-thum (simon-thum)]

Created an attachment (id=13692)
patch agaist X server

[Simon-thum (simon-thum)]

Created an attachment (id=13693)
Xinput proto - needed for Xserver

[Simon-thum (simon-thum)]

Created an attachment (id=13694)
proof-of concept runtime parameter adjustment

[Simon-thum (simon-thum)]

Created an attachment (id=13695)
proof-of concept runtime parameter adjustment

[Simon-thum (simon-thum)]

The structure is now OK, but changing parameters at runtime is not quite ready. It is however enough to try out and adjust the most important settings via the xinput tool. Comments encouraged!

[Simon-thum (simon-thum)]

Created an attachment (id=13697)
User documentation

updated documentation

[Peter Hutterer (peter-hutterer)]

(In reply to comment #39)
> Created an attachment (id=13692) [details]
> patch agaist X server
>

This patch is a bit messy.

CopySwapDeviceAccel() shouldn't even compile due to a stray "e->operation"

SendErrorToClient is not used in current master anymore. just BadMatch directly.

InitDefaultPointerAccelerationScheme(): you could just move the three lines to InitValuatorClassDeviceStruct and just have InitPointerAccelerationScheme. Or move them to the latter and have it as the default action if NULLs are provided.

what also makes me wonder is the high amount of commented lines. if they're not needed, just remove them.

can you fix these things please, then I can have another look at it.

[Peter Hutterer (peter-hutterer)]

(In reply to comment #40)
> Created an attachment (id=13693) [details]
> Xinput proto - needed for Xserver
>

I'd be better if DEVICE_PTRACCEL only takes up one spot and then you have a sub-variable for the scheme in the struct.

The range from DEVICE_PTRACCEL to DEVICE_PTRACCEL_MAX is a bit messy.

[Simon-thum (simon-thum)]

Created an attachment (id=13771)
patch for Xserver

I'm sorry!

I accidentally uploaded an old development snapshot of the Xserver patch. I meant this one :) Sorry for wasting your time with this!

> I'd be better if DEVICE_PTRACCEL only takes up one spot and then you have a
sub-variable for the scheme in the struct.

> The range from DEVICE_PTRACCEL to DEVICE_PTRACCEL_MAX is a bit messy.

Agreed. It was like this in the first place. I changed the design in order to support getting parameters (GetDeviceControl doesn't upload a struct to the server) plus keeping the possibility to get/set (rather) arbitrary parameters.

I thought it to be better than a loaded struct from which something will always be missing, especially if someone draws up additional schemes or the algorithm gets new tweaks. Maybe there is another way to do it?

[Peter Hutterer (peter-hutterer)]

(In reply to comment #47)
> > I'd be better if DEVICE_PTRACCEL only takes up one spot and then you have a
> sub-variable for the scheme in the struct.
>
> > The range from DEVICE_PTRACCEL to DEVICE_PTRACCEL_MAX is a bit messy.
>
> Agreed. It was like this in the first place. I changed the design in order to
> support getting parameters (GetDeviceControl doesn't upload a struct to the
> server) plus keeping the possibility to get/set (rather) arbitrary parameters.
>
> I thought it to be better than a loaded struct from which something will always
> be missing, especially if someone draws up additional schemes or the algorithm
> gets new tweaks. Maybe there is another way to do it?

there is a simple reason why the current approach is unsuitable. you're essentially making anybody else who may need to add a device ctrl dependent on your DEVICE_PTRACCEL_MAX.
Now in the worst case s.b. adds a DevCtl as MAX + 1. Clients depend on it and then when you add an accel scheme suddenly the absolute value of MAX + 1 has changed. This is bad!
Remember, #defines are compiled in so once they are in binary you can't change them anymore w/o recompilation.

I'm also not sure why the current approach gets around the problem of an "incomplete" struct. Maybe I'm misunderstanding you here?
What is wrong with

typedef struct {
    XID control; /* DEVIC_PTRACCEL */
    int length;
    int type;
} XDeviceAccelerationControl, XDeviceAccelerationState;

for the default, and then depending on the type you have a struct for each accel scheme that needs it. type determines which struct, and since length is in bytes anyway, nothing breaks by adding new schemes.

I'll have a look at the server patch but the inputproto stuff in its current state is a dealbreaker.

[Simon-thum (simon-thum)]

(In reply to comment #48)
> typedef struct {
> XID control; /* DEVIC_PTRACCEL */
> int length;
> int type;
> } XDeviceAccelerationControl, XDeviceAccelerationState;
>
> for the default, and then depending on the type you have a struct for each
> accel scheme that needs it. type determines which struct, and since length is
> in bytes anyway, nothing breaks by adding new schemes.
Looks good, absolutely on option. Let's call it option (1).
What it doesn't do is provide a simple way to add a parameter. You'll have to modify libXi, inputproto and modify marshalling (client and server). The current approach provides simple end-to-end transport - and by reserving a range incl. surplus we could be ABI safe too. (2)

OTOH, I'm not sure if it is desirable to have this ability at all.

> I'll have a look at the server patch but the inputproto stuff in its current
> state is a dealbreaker.
Would that still hold if the set of parameters was considerably smaller and with fixed codes assigned (and of course not resorting to range checks in switch() default: paths) ?
This would however mean not every knob is tweakable, a thing I'm fine with. (3)

Since libXi is yours, I'll leave the choice to you. My vote is for (2).

[Peter Hutterer (peter-hutterer)]

(In reply to comment #49)
> (In reply to comment #48)
> > typedef struct {
> > XID control; /* DEVIC_PTRACCEL */
> > int length;
> > int type;
> > } XDeviceAccelerationControl, XDeviceAccelerationState;
> >
> > for the default, and then depending on the type you have a struct for each
> > accel scheme that needs it. type determines which struct, and since length is
> > in bytes anyway, nothing breaks by adding new schemes.
> Looks good, absolutely on option. Let's call it option (1).
> What it doesn't do is provide a simple way to add a parameter. You'll have to
> modify libXi, inputproto and modify marshalling (client and server). The
> current approach provides simple end-to-end transport - and by reserving a
> range incl. surplus we could be ABI safe too. (2)

Ah. now I finally get it. I interpreted the parameters as different accel schemes rather than parameters for the same scheme.

Nevertheless, my proposal still holds. The length field is 16 bit, which should be enough to stack device controls. Something along the line of

typedef struct {
     XID control; /* DEVIC_PTRACCEL */
     int length;
     int type; /* which accel scheme */
     int parameters; /* number of parameters following */
} XDeviceAccelerationControl, XDeviceAccelerationState;

parameters simply states how many of the following.
length encloses the whole control (inc. all parameters) to be compatible with older versions.

typedef struct {
   int param_type;
   int length;
} XAccelParameterControl;

and then you have multiple versions of

typedef struct {
    int param_type; /* DevicePtrAccel_Coeff /*
    int length;
    int integer;
    int rational_num;
    int rational_den;
} XDevicePtrAccelCoeff;

this is a similar approach to what the ListInputDevices reply does with the classes.

advantages:
 we don't mess up the CONTROL range,
 we have _a huge_ range of parameters.
 the type field allows for multiple different accel types
 parameters are re-usable.

and 16 bit for the length should be enough for even multiple parameters.

does that make sense? any comments?

[Simon-thum (simon-thum)]

Created an attachment (id=14254)
patch: X server

[Simon-thum (simon-thum)]

Created an attachment (id=14255)
patch: libXi

[Simon-thum (simon-thum)]

Created an attachment (id=14256)
patch: xinput tool

[Simon-thum (simon-thum)]

Created an attachment (id=14257)
patch: Xinput proto

[Simon-thum (simon-thum)]

Created an attachment (id=14258)
Documentation

The XDeviceConrol interface has been reworked and should conform better now. The server-side implementation is considered complete. xinput has some rough edges but is useable.

[Daniel Stone (daniels)]

FWIW, my final intention for this is 1.6, once I've finished the property code, since I'm loathe to add an API and then swiftly remove it. Currently working on XKB stuff, but should be back on to Xi by the end of the month. I don't have any real concerns with the patches, so any distros that want to merge this are welcome to.

[Thomas Bertels (the-redburn)]

I think sensitivity and acceleration are linked. I mean it is now, but it shouldn't.

Sensitivity should be the basic setting. Acceleration should be added on top of the sensitivity.

See http://brainstorm.ubuntu.com/idea/7815/ for an idea.

[Thomas Bertels (the-redburn)]

There's a proposed patch in https://bugs.freedesktop.org/show_bug.cgi?id=2927 which adds the possibility to change the mouse sensitivity independently from the acceleration.

With that patch, we can change the sensitivity thumb from mouse options to really control the sensitivity, not the threshold.

And with https://bugs.freedesktop.org/show_bug.cgi?id=8583 the acceleration will also be improved. The question is : how to let set this new adaptive deceleration setting ?

[Simon-thum (simon-thum)]

Created an attachment (id=17544)
patch against X server

This patch should apply against current git.
Small changelog:
-A minimal interface for device drivers has been added (fully optional)
-The velocity guessing is cleaner and potentially even more precise
-the runtime parameter changing stuff has been removed
-'classic' compatibility functions are now selectable as own profiles

[Simon-thum (simon-thum)]

Created an attachment (id=17545)
documentation

the user-unfriendly documentation ;)
might miss a few bits, but correct in general

[Simon-thum (simon-thum)]

Created an attachment (id=17626)
revised patch

didn't include important parts, this patch should be complete now.

[Peter Hutterer (peter-hutterer)]

Pushed as c9eb0e870c87d291311491452adf7f91a911e24b

[Simon-thum (simon-thum)]

Created an attachment (id=17772)
updated developer documentation

The attached doc should match with current git servers.

Contrary to what some people linking here stated, this effort was not commited until recently. This makes it a likely item in X11R7.5.

Until then, you have to use the patches here if you want it.

[Simon-thum (simon-thum)]

Created an attachment (id=17773)
patch for Xorg server 1.4.x

This patch should apply against 1.4 servers.

[Psy[H[] (vovik-wfa)]

Filed a bug for gnome: http://bugzilla.gnome.org/show_bug.cgi?id=563777

[Endolith (endolith)]

It feels like "Acceleration" in Gnome control center corresponds to the constant multiplier "acceleration" in xset, and "Sensitivity" in Gnome corresponds to "threshold" in xset. If you set acceleration high and sensitivity low, it's impossible to move one pixel at a time. If you set sensitivity high, you can move within a large range one pixel at a time before it starts jumping. If you set acceleration to "slow" and sensitivity to high, it actually slows down if you move faster.

This two-step acceleration is pretty much garbage for a real mouse, but works somewhat for a touchpad. For a real mouse, I have found that "xset m 11/8 0" works best, using the hidden "set threshold to 0" feature that uses a smoothly-varying acceleration instead of the jerky two-step.

See http://ubuntuforums.org/showthread.php?t=748412#4

[Traz (traz)]

I also have an issue with this. I dont like any acceleration, this means that the cursor should move no matter how fast I move my mouse.

Surprisingly in intrepid, I achieved this by setting the acceleration bar to the right and the sensitivity bar to the left.

In jaunty, i'm unable to set the cursor speed to fast and no acceleration at all.

[Psy[H[] (vovik-wfa)]

with all the tools now available in X, it would be great to have the following properties in gnome-mouse-properties:

speed (general linear speed multiplier)
acceleration (non-linear speed modifier)
threshold (distance before acceleration)

And name them correctly, because it is misleading when threshold slider is named "sensitivity", to put it mildly.

also current visualization in g-m-p is very unhandy. Slider does not give any useful information, nor it gives the ability to set proper values. A text field is needed to see and modify numeral values.
For example I have to use gconf-editor to set acceleration strictly to "1" in order to disable it, because there is no way to tell which value is set with slider.

[Bryce Harrington (bryce)]

Thanks for your note, and I think you have some good points.
But note that the ubuntu-x-swat team does not maintain the gnome tools,
just the underlying bits. I'd encourage you to bring your feature ideas
to the gnome-desktop team.

On Wed, Jan 06, 2010 at 10:37:06PM -0000, Psy[H[] wrote:
> with all the tools now available in X, it would be great to have the
> following properties in gnome-mouse-properties:
>
> speed (general linear speed multiplier)
> acceleration (non-linear speed modifier)
> threshold (distance before acceleration)
>
> And name them correctly, because it is misleading when threshold slider
> is named "sensitivity", to put it mildly.
>
> also current visualization in g-m-p is very unhandy. Slider does not give any useful information, nor it gives the ability to set proper values. A text field is needed to see and modify numeral values.
> For example I have to use gconf-editor to set acceleration strictly to "1" in order to disable it, because there is no way to tell which value is set with slider.
>
> --
> Improve mouse sensitivity and acceleration settings
> https://bugs.launchpad.net/bugs/28052
> You received this bug notification because you are a member of Ubuntu-X,
> which is a direct subscriber.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ubuntu-x-swat
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~ubuntu-x-swat
> More help : https://help.launchpad.net/ListHelp

[meral (meral)]

Even if I put sensitivity and acceleration to the max, the mouse is still way too slow.
Can't I somehow reset this interval of changement possibility? I use a thinkpad trackball.

[AmenophisIII (amenophisiii)]

meral: for me setting acceleration fast (right) and sensitivity low (left) gives a fast motion in lucid.
i just noticed it myself... stupid gui :/

[Colin Law (colin-law)]

Could someone clarify here, is all the above saying that it is known that the mouse sensitivity setting does nothing and that to make it do something is a wishlist item rather than a bug? Seeing this on 11.04 and 11.10.

[Ermenegildo Fiorito (fiorito-g)]

Also affects me.
(Ubuntu Precise)

[Will Rouesnel (w-rouesnel)]

The mouse settings on the Gnome Control Center are misnamed and misrepresentative.

I suspect a lot of people are adjusting "Sensitivity" and expecting the pointer to get faster, but sensitivity is actually just the motion threshold before the "Acceleration" multiplier is applied - and none of this is explained in the UI.

"Acceleration" needs to be renamed "Pointer Speed" or something. Sensitivity can then be left as is, since it'll make more sense in context.

The other thing is that the "Sensitivity" slider is both backwards AND misrepresentative. It represents a value in pixels from 1 to 10, so huge parts of it's adjustment don't do anything. It needs to be notched so it's apparent it's a very limited integer representation. It also needs to be reversed - the common interpretation of a "sensitive" mouse is one which is twitchy - but adjusting sensitivity to high set's the motion-threshold to 10, which means the mouse is actually very slow since acceleration takes a lot of movement to apply.

Finally, both of these sliders should probably have text input boxes next to them showing the exact numerical values they currently represent and allowing people to enter ones outside the current ranges - this would accomodate edge cases where it's not enough.

[Shiki (shiki)]

Seriously just add an option for acceleration. Please.
I can set acceleration via xinput, but damn it's 2013.

[Shiki (shiki)]

Okay, this bug should be closed. It's not even relevant anymore.
But the new control center is still missing the option to set the acceleration properly. (There is none.)

$ xset m 0 0
will fix this.

I have found a way to make this auto-start each boot:

1) Open up a terminal and type:

#!/bin/bash
xset m 0 0

Save the file in your home folder as “mouse.sh” or anything. Just make it end with “.sh”.

2) Let’s make this file executable.
chmod +x ~/mouse.sh

3) Let’s make Ubuntu run it automatically at each boot!
Open up the application called “Startup Applications”, and add a new one.
Name: whatever you want.
Command: ~/mouse.sh

( Source that I found through Google: http://blog.repa.info/2013/06/14/how-to-disable-mouse-acceleration-in-ubuntu-or-any-other-linux/ )