I have a webpage on the topic of the mouse in XFree86:
http://www.ijs.co.nz/linux-orbiting-mouse.htm
At 2002\10\31 18:20 -0800 Thursday, Michael Toomim wrote:
>I propose adding an option to the XF86Config mouse settings that lets a
>user modify the mouse speed dynamically with xset, rather than with the
>Resolution option in XF86Config.
>
>Right now, "xset m acceleration threshold" means:
>
> "Move the cursor at speed `acceleration*raw_mouse_speed' whenever
> `raw_mouse_speed' is greater than `threshold' -- unless `threshold'
> is 0, in which case the cursor will move at
> `raw_mouse_speed^acceleration'."
>
>This last feature (with threshold=0) is completely undocumented. In
It is also not available to KDE users (who can't get the threshold down
to 0, if I recall correctly).
Anyway, the unavailable algorithm maybe is no better (or if it is, then
comparing the two is going to produce indecision over which is better).
>addition, there's no way to speed up the mouse by a constant multiplier
>(independent of acceleration) without changing the "Resolution" option
>in XF86Config. This requires a server restart, root access, isn't
>documented in XF86Config's man page, isn't supported for all mice, can't
>be customized per-user, and doesn't really make sense ("Resolution" is
>inversely proportional to "MouseSpeed").
>
>The right way to do mouse acceleration is to have a smooth acceleration
>curve (like the polynomial you get with threshold=0) and to let the user
That is not correct because the data going into the functions. is mainly
(dx,dy) taking these values: (0,0),(1,0),(-1,0),(0,1),(0,-1). It might
be different if some high resolution expensive mouse gets around the
problem. Such things are not needed when Windows 2000 is used.
To get the digits +/-2 to show up, when there is a plain Microsoft PS/2
mouse, then a speed that is often not reached, is needed.
>control both the acceleration and a constant multiplier dynamically (not
>in XF86Config). For example, it'd be great if "xset m [A] [B]" made the
>cursor move according to the formula "[A] * raw_mouse_speed^[B]".
It is a 2-D curve.
Also it has a discontinuity in it which is a bug. The effect of the bug
would be to make the mouse orbit around that stopping point. I tried
removing the bug but it was not any better. The function ought be
replaced eventually even though it seems to me that most of the problem
is due to the missing code to do averaging of dx,dy integers.
>
>Proposal: Add a boolean option to XF86Config called
>"UseSmoothMouseAccel" that changes the behavior of xset. If this
>variable is set to true, the command `xset m [A] [B]' will mean "set the
>cursor movement function to `[A] * raw_mouse_speed^[B]'".
>
While the bad problem of an absence of code to average mouse data (for
a plain XFree86 configuration), is not remedied, then other problems
can't easily be fixed, due to reviewers being unable to decide if the
change made the mouse better or worse. After that there could be a
problem of too many possible algorithms.
It could be nice to shift disputes over retaining the meaning of the
sliders in GNOME and rewriting the parameters, out to the desktop
bug tracking systems, so it does not add disputes unnecessarily to
the topic of whether copying the mouse algorithm of Windows 2000/Timeout
is best.
The problems are inside of the xf86PostMotionEvent() procedure, which can
be viewed at this URL:
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86Xinput.c
>This will also require some way for client X applications (like gnome's
>mouse settings applet) to determine the value of "UseSmoothMouseAccel", etc.
>
>Comments? There has been scattered discussion of possible ways to
>improve XFree86's mouse acceleration in the past, but there haven't been
>many practical solutions suggested. I'd really like to get this cobweb
>cleaned up.
I am guessing people would prefer hundreds of iterations recompiling.
A quickest way could be to start out compiling some Windows program.
Tapping into Windows 2000 mouse data and then inferring from an analysis
of the data should allow the Microsoft algorithm to be precisely
copied. They have a worse mouse deceleration algorithm in Windows 98 SE,
and possibly the best effort of someone could produce something as bad,
Anyway, for many, having the mouse be about identical to a Windows 2000
mouse is aim independent of one of having the behaviour be unimprovable.
---
To fix the bad design of the sliders in GNOME and KDE could justify a
preprocessing subroutine/procedure that alters the parameters that then
pass into the mouse pointer deceleration algorithm. Possibly they might
want to control the rewriting of the parameter integers but not
provide their own new mouse deceleration code.
Would someone say how to get debugging data piped out of XFree86 and
put into a window in XFree86 in any OS. Any sample code to copy?.
Craig Carey <[EMAIL PROTECTED]> Auckland, New Zealand
Ada 95 mailing lists; http://www.ijs.co.nz/ada_95.htm
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
