At 2002\11\01 23:01 -0800 Friday, Michael Toomim wrote: >At 2002\11\02 17:22 +1300 Saturday, Craig Carey wrote:
Correction: dx' = k1 * * (+1 if dx > 0 else -1) >> dx' = k2 * dx >> >> [dx is a C int, dx' is real that is added to a real sum and then >> later converted into a screen pixel position] > >I think we're miscommunicating here. My issue has nothing to do with >problems with small integers. I just want to be able to control the >mouse speed (not acceleration) with xset. > >Since these two issues are orthogonal, let's try to keep them in >separate threads. > That can be rejected. Here are my arguments for doing that. It would not be a great problem to have a new thread. Here are some arguments having considerations of deceleration appear in this thread: (1) The 31 October 200 message of Mr Toomim, which started the thread, was all over the topic of the deceleration function and it even mentioned that the a power function was used, thus the small procedure implementing the deceleration probably was located. (2) The title contains the words "mouse ... acceleration", so the subject field contained the topic. Not many messages here do contain the topic and I was only replying to other pre-existing threads on the topic of the deceleration algorithm; (3) That first message of the thread had a significant purpose of having XFree86 altered so that the constant that is multiplied in, and that provides the accelerating, could be increased in real time. That is verifiable: (4) A singe mathematical expression contains the multiplier and the 'threshold' value that (mis)splices two curves together ------ 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 ... >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 ------ Anyone can modify XFree86 and then increase the amplifying number. But then this problem appears: a very small motion of the hardware mouse will cause an approx. 20 pixel jump of the mouse cursor. That is due to a lack of averaging code that is major cause of the overshooting mouse with its dead diamond shaped region in the velocity plane. Both the fast mouse and the slow mouse, are affected. At 02\11\01 23:58 -0800 Friday, J. Imlay wrote: ... >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) Quite so: GNOME and KDE are unusable. However GNOME shut down bug reports saying that it is an XFree86 problem. I think KDE was not processing their bug report. ... >But lambasting people for commenting there opinions on this matter as >being off topic (even if they are) doesn't get any of us anywhere. The author did not have backing of his message or the details of the topic and this looks like an instance where users expect such patches to never make it into the code. That code seems to be in a C coding style: memcopy's, and no type checking, and bugs [e.g. the discontinuity at the edge of the diamond shape, and missing averaging code, and unnecessary loss of accuracy in the arithmetic (use of "(int)")]. To provide averaging code won't alter the behaviour of the sliders in GNOME and KDE so in addition to having very easy to write code that would produce a noticeable improvement, it ought be able to avoid being controversial. Obviously a fix is needed (I am not intending to produce a patch for months). The mouse deceleration algorithm: xf86PostMotionEvent(): http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86Xinput.c Craig Carey Auckland, New Zealand Craig Carey _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
