Created attachment 23384 [details] [review]
107_reduce_cursor_speed.patch

Do you have any statistical data on how many users are affected by this "bug"?
Are your defaults superior to the current ones, and if so, how did you
determine this?

What was the min/max speed setting for your hardware before? Has it changed?
The server has new pointer acceleration code, so it may be that you're
actually seeing the effect of that.

Could you please tell me how can I get Speed? Sorry, but I am unfamiliar with synaptics stuff as I haven't had any problems with older releases.

No, I don't have staistical data for it. I simply noticed that, after updating the driver, the cursor moves faster than before and it's a bit hard to control. If you could tell me how to get "measures" for it, I would try to get them

Thanks a lot

> --- Comment #3 from Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>  2009-02-28 03:21:53 PST ---
> Could you please tell me how can I get Speed? Sorry, but I am unfamiliar with
> synaptics stuff as I haven't had any problems with older releases.

There's three settings: MinSpeed, MaxSpeed and AccelFactor. Just play around
with them to see which one is the one the old driver had.

Now, the important thing is that you get the values from the old driver too.
If the old driver had MinSpeed 0.7 and now it has - say - 1.5, this shouldn't
happen.
If the values are the same (or roughly anyway), then it's the server's accel
code kicking in.

> No, I don't have staistical data for it. I simply noticed that, after updating
> the driver, the cursor moves faster than before and it's a bit hard to control.
> If you could tell me how to get "measures" for it, I would try to get them

Well, unfortunately the only hard measures you can get on this is to perform a
scientific study with a significant number of users from a randomised sample
pool. everything else is anecdotal evidence, which keeps us in bit of a loop
(your opinion vs. the next bugreporter's opinion).

(In reply to comment #4)

Seems that they changed:
- MinSpeed from 0.09 in old to 0.4 in new 
- MaxSpeed from 0.18 in old to 0.7 in new
- AccelFactor was 0.0015 and now, I don't know, as grepping "AccelFactor" in new sources only gives me:

src/synaptics.c:    pars->accl = synSetFloatOption(opts, "AccelFactor", accelFactor);

(In reply to comment #5)
> Seems that they changed:
> - MinSpeed from 0.09 in old to 0.4 in new 
> - MaxSpeed from 0.18 in old to 0.7 in new
> - AccelFactor was 0.0015 and now, I don't know, as grepping "AccelFactor" in
> new sources only gives me:

wait, did you get this from the source or from the actual device? if you run xinput --list-props <synaptics device name> what's the factors there? (synclient -l does the same)

The server and the driver definitely accelerate independent of each other, I just played around with this for a bit. There's two methods of configuration:

1. Switch off xserver acceleration for the touchpad:
drop the following into a file in /etc/hal/fdi/policy/

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
      <match key="info.capabilities" contains="input.touchpad">
          <merge key="input.x11_options.AccelerationScheme" type="string">none</merge>
      </match>
  </device>
</deviceinfo>


2. switch off driver acceleration:
Set MinSpeed and MaxSpeed both to "1". This may make the touchpad even faster than before, so you may need constant deceleration. The configuration for this is:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
      <match key="info.capabilities" contains="input.touchpad">
          <merge key="input.x11_options.ConstantDeceleration" type="string">2</merge>
          <merge key="input.x11_options.MinSpeed" type="string">1</merge>
          <merge key="input.x11_options.MaxSpeed" type="string">1</merge>
      </match>
  </device>
</deviceinfo>

Either way, you need to restart HAL before restarting X.

Created attachment 24307 [details]
unproper-factors

This is the output with default (and too fast mouse)

Created attachment 24308 [details]
xorg-disabled-factors

Switching off xorg accel seems to behave better :-)

Created attachment 24309 [details]
driver-accel-factors

With the last option, mouse moves as fast that it's hardly controllable :-(

For me, disabling xorg accel is the best

(In reply to comment #9)
> Created an attachment (id=24309) [details]
> driver-accel-factors
> 
> With the last option, mouse moves as fast that it's hardly controllable :-(

you need to increase ConstantDeceleration in this case. I found 2 or 3 to be ok, but Simon (who wrote the accel code) mentioned he needs 9 on his touchpad.

what's rather interesting though is that in all three synclient outputs you attached, the RightEdge is different (the other values stay the same). This shouldn't happen, RE should always be what the hardware reports (minus an edge setting margin based on the hw's dimensions).

I think the important point is that the synaptics acceleration is actually a deceleration. Even MaxAccel is usually below 1.

The old and current velocity approximation algos both are vulnerable to noise. While the current algorithm has opportunities to make it noise-resistant, I think noise shouldn't be passed out of drivers.

Depending on the device, MinAcc = MaxAcc = 0.33 or 0.25 should be applied to reduce noise. Then, using dix ('xorg') acceleration should yield optimal results.

An ideal fix would be to let the driver apply downscaling until noise is negligible, and let constant deceleration cover the rest. 

Acceleration could then be done in a device-specific profile, since there seems to be no direct equivalent of the synaptics accel function among the existing ones. This function could be limited to [1..MaxAcc/MinAcc] so behaviour is roughly equal.

(In reply to comment #11)
> An ideal fix would be to let the driver apply downscaling until noise is
> negligible, and let constant deceleration cover the rest. 
Ok, I just re-checked with latest synaptics. I don't know excatly what changed, since my measurements were against a pre-Xorg synaptics.

For the record: MinAcc = MaxAcc = 1 is ok. No significant noise to see.
Still, it's too responsive for daily use, but I got it with constant decel = 3 and polynomial acceleration. That's roughly what synaptics does on it own.

(In reply to comment #10)
> you need to increase ConstantDeceleration in this case. I found 2 or 3 to be
> ok, but Simon (who wrote the accel code) mentioned he needs 9 on his touchpad.
> 


I have just tried with 2, 3, 5, 9, 13, 15, 35 and I get similar behaviors :-/

Thanks for your attention :-)

(In reply to comment #13)
> I have just tried with 2, 3, 5, 9, 13, 15, 35 and I get similar behaviors :-/
What's your X server version? I guess with 1.5.x you have props but not the new accel code, so it's in fact pointless to set constant deceleration :)

Hope it helps:

The problem, in my case, was that KDE used >xset m< to set accel, thereby imposing a double accel onto the pad. Users may disable server-side acceleration for the pad only (i.e. not for other devices) using:

> xinput set-ptr-feedback <device> 1 1 1

Then you'll have to readjust pad acceleration, but the end result is better IMO.

> --- Comment #14 from Simon Thum <simon.thum@gmx.de>  2009-04-06 22:26:04 PST ---
> (In reply to comment #13)
> > I have just tried with 2, 3, 5, 9, 13, 15, 35 and I get similar behaviors :-/
> What's your X server version? I guess with 1.5.x you have props but not the new
> accel code, so it's in fact pointless to set constant deceleration :)

server 1.6 has properties and the accel code, 1.5 doesn't have either.
atm, you can only change the accel properties at runtime if you're running a
server from git.

I have xorg-server-1.5.3

Sorry for the delays in replies, but I am really busy in "real life" these days

This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it.

Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.