J. Imlay wrote:
I am just a casual reader on this list so I could be entirly wrong about
all this.

I've read the thread that you started last spring, and I've been following
this one, and I sympathize with you on the problems with the acceleration
in X (it's down right unusable IMHO) but what I'm missing is what you are
actually trying to get at?
Here's what I'm trying to get at: I think that the constant multiplier should be settable with xset, instead of requiring one to modify the Resolution option in XF86Config.

The issue was brought up last spring, and appearantly nothing was done
about it.
Since there's some confusion about that, let me explain how this thread relates to last spring's thread.

The issue disappeared from the mailing list, but I had some discussion offline with Joe Krahn about it after the mailing list posts that you saw. During that discussion, I communicated with the woman who researched mouse acceleration algorithms at Apple, and she told me what algorithm Apple used and what her methodology was to come up with the algorithm. In the end, my plan was to follow her methodology, and write a test application with which to experiment with different acceleration algorithms. But I aborted this plan pretty quickly because I figured out how to make the existing algorithm work acceptably:

The trick is just to use the polynomial algorithm (by doing "xset m n/d 0" or the like, where n and d are numbers, ie. "xset m 18/10 0" works well), and then to modify the Resolution option in XF86Config to taste.

I use a basic logitech wheel mouse (I think it's called the "first mouse"), and I've found these settings to work really well for me:

xset m 29/20 0 # in .xinitrc
Option "Resolution" "200" # in InputDevice section of XF86Config-4

(But be sure that the "xset m 29/20 0" command is executed after X starts and your gnome/kde/whatever settings daemon clobbers the mouse rate. My current solution is to call the script "fixmouse-repeat&" in .xinitrc before gnome-session, where fixmouse-repeat does: "fixmouse;sleep 1;fixmouse;sleep 1;fixmouse;sleep 1;..." and fixmouse does "xset 29/20 0" in order to be sure that my xset settings take effect after gnome's.)

This will make your mouse cursor move according to the function "A * raw_mouse_speed^B", where A = some_constant/Resolution and B = n/d = 29/20.

This setup works really well for me! The only problem is that it was a bitch to figure out the right values for Resolution and n/d (the exponent), since you have to restart X and modify XF86Config every time I wanted to change the constant multiplier.

Now, we've all been worried about finding a good mouse acceleration algorithm that suits more than a particular hacker's personal taste. But I think that the polynomial function that you get with threshold==0 really IS "good enough" for all users! I challenge everyone interested to try the polynomial function (set `threshold' in "xset m N/D threshold" to 0) and see if you can't find some parameters that make it work well for you. Really, I think that once you try it (and get a good value for the Resolution and exponent) you'll agree that we don't need any more complicated algorithm.

Thus, right now I think the best solution would be to just keep the polynomial algorithm already implemented in XFree86, and simply implement some way of changing the constant multiplier with xset. The problem is that it's hard to just go and add an extra run-time parameter to xset, since it involves modifying the X network protocol... here's an excerpt from a correspondence I had with Joe Krahn about this:

Anyway, is it ok to extend the xset syntax?

The problem is that this means changing the X network protocol.
Remember xset is a client. However, a mechanism for general
and more complex device control commands will be implemented
before long. For now, such advanced things would have to go
into XF86Config, and be stuck at runtime. Actually, we could use
integer Feedbacks to do it, buit that would be a temporary hack
until better device controls exist.
Xset lets us modify 3 numbers at runtime, but if we're using the polynomial function we only have 2 numbers (since the third has to be set to 0). If we want to be able to modify the constant multiplier at runtime, we have to somehow do it with the numbers xset already gives us. One option is the proposal I gave to start this thread (add a boolean option to XF86Config that changes the meaning of xset). Another option is to remove support for the 2-level "threshold" acceleration algorithm entirely, and require people to use the polynomial "power" function (which is what Soeren's patch does). A third option would be to split the exponent of the power function (the numerator and denominator) into two distinct values -- one for the exponent and one for the constant multiplier.

Of these options, I like the first two the best. The third option would really munge xset syntax -- to make the mouse move as "3*raw_speed^2" you'd have to say "xset m 3/2 0", which isn't very intuitive. (Note that you usually want to express non-integer values like 3.4 and 1.87, so the actual function would be 3/multiplier_constant * raw_speed^(2/exponent_constant).)

So between the first two options, my proposal retains backwards compatibility and Soeren's gives it up. Personally, I'd prefer to give up backwards compatibility, as I don't believe there is anybody who actually *prefers* the threshold-multipler acceleration. But a safer route might be to introduce the option first, and then to phase it out slowly as people and desktops begin to support it.

_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to