Attachment 68 Details for Bug 138 – Mail from eugenia with proposed algorithm.

Mail from eugenia with proposed algorithm.

mouse.txt (text/plain), 16.99 KB, created by Jim Gettys on 2003-11-06 08:30:04 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jim Gettys

Created: 2003-11-06 08:30:04 UTC

Size: 16.99 KB

patch

obsolete

>From eugenia@osnews.com Wed Nov  5 15:08:40 2003
>Return-Path: <eugenia@osnews.com>
>Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net
>	[16.47.68.171]) by quabbin.crl.dec.com (8.12.10/8.12.10) with ESMTP id
>	hA5K8eHq108470 for <jg@quabbin.crl.dec.com>; Wed, 5 Nov 2003 15:08:40 -0500
>	(EST)
>Received: from zcamail02.zca.compaq.com (zcamail02.nz-cac.cpqcorp.net
>	[161.114.40.102]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id
>	CE9302797 for <jg@quabbin.crl.dec.com>; Wed,  5 Nov 2003 14:08:38 -0600
>	(CST)
>Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by
>	zcamail02.zca.compaq.com (Postfix) with ESMTP id 22B6A16198 for
>	<jg@quabbin.crl.dec.com>; Wed,  5 Nov 2003 12:08:38 -0800 (PST)
>Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by
>	palrel10.hp.com (Postfix) with ESMTP id DC5481C02710 for
>	<jg@quabbin.crl.dec.com>; Wed,  5 Nov 2003 12:08:37 -0800 (PST)
>Received: from wera.hpl.hp.com (wera.hpl.hp.com [15.9.120.80]) by
>	hplms2.hpl.hp.com (8.12.10/8.12.10/HPL-PA Hub) with ESMTP id hA5K8Wg3005396
>	for <jg@quabbin.crl.dec.com>; Wed, 5 Nov 2003 12:08:37 -0800 (PST)
>Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net
>	[16.47.68.171]) by wera.hpl.hp.com (8.12.10/8.12.9) with ESMTP id
>	hA5K8VEh014387 for <jg@pa.dec.com>; Wed, 5 Nov 2003 12:08:32 -0800 (PST)
>Received: from ztxmail01.ztx.compaq.com (ztxmail01.nz-cce.cpqcorp.net
>	[161.114.8.205]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id
>	2C6CE260B for <jg@pa.dec.com>; Wed,  5 Nov 2003 14:08:31 -0600 (CST)
>Received: from ccerelrim04.cce.hp.com (ccerelrim04.cce.hp.com
>	[161.114.21.25]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id
>	DCB84C176 for <jg@pa.dec.com>; Wed,  5 Nov 2003 14:08:30 -0600 (CST)
>Received: from ccerelrim04.cce.hp.com (localhost.localdomain [127.0.0.1])
>	by receive-from-antispam-filter (Postfix) with SMTP id 6693A32E84 for
>	<jg@pa.dec.com>; Wed,  5 Nov 2003 14:08:01 -0600 (CST)
>Received: from birch.he.net (birch.he.net [216.218.139.98]) by
>	ccerelrim04.cce.hp.com (Postfix) with ESMTP id ABA2332F16 for
>	<Jim.Gettys@hp.com>; Wed,  5 Nov 2003 14:07:29 -0600 (CST)
>Received: from eugenia (12-236-207-10.client.attbi.com [12.236.207.10]) by
>	birch.he.net (8.8.6p2003-03-31/8.8.2) with SMTP id MAA30514; Wed, 5 Nov
>	2003 12:07:55 -0800
>Message-ID: <00b801c3a3d8$818f6e30$0a00000a@eugenia>
>From: "Eugenia Loli-Queru" <eugenia@osnews.com>
>To: "Jim Gettys" <Jim.Gettys@hp.com>, "Mike A. Harris" <mharris@www.linux.org.uk>
>Cc: "Keith Packard" <keithp@keithp.com>
>References: <01f101c3a340$3425e900$0a00000a@eugenia>
>	 <Pine.LNX.4.58.0311050028330.5255@zod.capslock.lan>
>	 <1068036610.3554.23.camel@laptop.gettys.org>
>Subject: Re: new x server
>Date: Wed, 5 Nov 2003 12:07:57 -0800
>Organization: OSNews
>MIME-Version: 1.0
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook Express 6.00.2800.1158
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
>X-PMX-Version: 4.0.4.77969
>Content-Type: text/plain; charset=iso-8859-1
>X-Evolution-Source: imap://jg@localhost/
>Content-Transfer-Encoding: 8bit
>
>> Mike, see if you can get some time to work on it.  If not,
>> we should put out a call for volunteers.
>
>The code below is similar to the BeOS way, and I think XP is using the same
>technique (both OSes have the best feel mouse-wise of anything I have ever
>used -- and I use a lot of different stuff ;). Mac OS X still uses the old
>technique, with thresholds, and that's why all pre-Panther versions sucked
>badly mouse-wise. Panther has better settings and it is more comfortable
>using it, but the problem is still there and I hit it many times a day when
>using it.
>
>/* not sure it compiles, but the main idea is right here */
>
>static unsigned long last_motion_time=0;
>static float x_carryover=0, y_carryover=0;
>static float speed_factor=1;
>static float acceleration_factor=0;
>
>void accelerate_mouse(int x_in,int y_in,int*x_out,int*y_out)
>{
>  unsigned long now;
>  unsigned long time_elapsed;
>
>  float speed;
>  float scaled_x,scaled_y;
>
>  now=get_time_in_microsecs();
>  time_elapsed=now-last_motion_time;
>
>  last_motion_time=now;
>
>  speed=sqrtf((x_in*x_in+y_in*y_in)/time_elapsed*time_elapsed);
>
>  scaled_x=x_in/speed;
>  scaled_y=y_in/speed;
>
>  speed*=speed_factor;
>  speed+=acceleration_factor*speed*speed;
>
>  scaled_x*=speed*time_elapsed;
>  scaled_y*=speed*time_elapsed;
>
>  scaled_x+=x_carryover;
>  scaled_y+=x_carryover;
>
>  *x_out=truncf(scaled_x);
>  x_carryover=scaled_x-*x_out;
>  *y_out=truncf(scaled_y);
>  y_carryover=scaled_y-*y_out;
>}
>
>* Speed factor compensates for the resolution of the mouse, so if you have a
>cheap-a$$ 200dpi mouse will work the same way as a 2000 dpi one.
>* when the acceleration factor is 0 you get linear motion (no thresholds,
>thresholds are bad (TM) and limited)
>* The two carry_over variables are here to prevent aliasing from the
>truncation/rounding. So you get smooth feel all the time.
>* Important: Acceleration and speed are and should be different, and the
>preference panels on KDE/Gnome should have BOTH "Speed" and "Acceleration"
>sliders. The slider for the speed factor should be logarithmic. Acceleration
>factor, probably linear or possibly quadratic (tests will be required to see
>which feels better)
>* The algorithm needs to be in a place where it can get low latency from the
>IRQ. Interrupt handler is one of those places, it can be in the user space
>if the kernel can do low latency scheduling from the interrupt handler to
>the user space, or even to the kernel space (kernel thread). I think it
>should be fine on the user space though, especially with linux 2.6. If the
>architecture doesn't do that, it is time to rethink the linux/unix
>architecture then. ;-)
>
>That's it, please feel free to use that chunk of code. That should give you
>the a mouse feel smoother than an android's bottom (Star Trek joke ;) and I
>am convinced that this will stop people from saying "X feels clunky" without
>being able to pinpoint "why".
>
>thanks,
>Eugenia
>
>
>----- Original Message ----- 
>From: "Jim Gettys" <Jim.Gettys@hp.com>
>To: "Mike A. Harris" <mharris@www.linux.org.uk>
>Cc: "Eugenia Loli-Queru" <eugenia@osnews.com>; "Keith Packard"
><keithp@keithp.com>
>Sent: Wednesday, November 05, 2003 4:50 AM
>Subject: Re: new x server
>
>
>> Maybe fixing mouse handling should be a candidate for the
>> xfixes extension.
>>
>> Mike, see if you can get some time to work on it.  If not,
>> we should put out a call for volunteers.
>>
>> Have any idea exactly what XP and/or Aqua is doing?
>>                             - Jim
>>
>> On Wed, 2003-11-05 at 01:05, Mike A. Harris wrote:
>> > On Tue, 4 Nov 2003, Eugenia Loli-Queru wrote:
>> >
>> > Hi Eugenia!
>> >
>> > >great news on the developments of your xfree86 version. My best wishes
>on
>> > >the project!
>> >
>> > The project isn't really a new XFree86 version per se.  The
>> > xserver portion of the freedesktop.org project is actually an X
>> > server which Keith wrote a number of years ago called "kdrive"
>> > which is included in XFree86's codebase as well.  The kdrive
>> > servers aren't built by default when you compile XFree86, but
>> > they're there and are used on PDAs and other embedded devices
>> > quite often due to their tiny size, etc.
>> >
>> > While the kdrive code was previously maintained by Keith inside
>> > the XFree86 source code tree, the code was moved to the
>> > freedesktop.org project to allow Keith as well as other
>> > developers to work much more closely on it to develop
>> > experimental new X technology and extensions, etc.  It's kindof a
>> > testbed for new fun stuff so to speak.
>> >
>> > Also, there are other projects like the X libraries, etc. which
>> > are alternatives to the ones found in XFree86, and should be
>> > fully compatible as well.  Those are also based upon the X
>> > libraries found in XFree86.  Currently however, the core XFree86
>> > X server is only available from XFree86.org, only Keith's kdrive
>> > X server is part of freedesktop.org, at least for the time being.
>> > ;o)
>> >
>> > Just thought I'd mention these few things in case there might
>> > have been any confusion.
>> >
>> >
>> > >Please let me point out something very important IMHO, that
>> > >often people do not realize: the mouse drivers are all broken on
>> > >X for the last few years. It wasn't that bad a few years ago
>> > >(e.g. 1997-8 era). What I mean is that the current PS/2 and USB
>> > >drivers are just not presice, many times I just can't grab
>> > >specific "thin" UI elements, it requires extra effort to do so.
>> > >And also, if you move your mouse slowly, nothing happens, the
>> > >mouse cursor doesn't move. I have tried with multiple mice (MS,
>> > >logitech and many no name ones), different drivers/protocols,
>> > >different distros, different machines, heck even different
>> > >architectures, they ALL exhibit the same problem with the new X
>> > >servers, so I know it is not just me or my settings.
>> >
>> > Yes, I know exactly what you mean.  It's not the drivers that are
>> > broken per se though.  It's possible that there are some mice
>> > that aren't supported well or at all, or that there are a few
>> > protocol glitches here and there, and that definitely needs
>> > improvement for sure.  The problem you're describing is more of a
>> > problem in the layer(s) above the mouse driver itself, and is
>> > something that really does tend to suck in the XFree86 X server
>> > currently, and for years now.
>> >
>> >
>> > >The only OSes that I know that have very smooth mouse
>> > >acceleration and they don't depend on rounding down based to
>> > >threshold/acceleration info (old technique) is IRIX,
>> > >Windows9x/XP and BeOS. Even OSX Jaguar was almost terrible in
>> > >this regard until recently, but Panther fixes the problem (but
>> > >does not illiminate it, they just adjusted their settings, not
>> > >their architecture).
>> >
>> > Indeed, XP has very nice mouse handling.
>> >
>> >
>> > >So, it is very cool to get double buffering and 3D stuff, but
>> > >someone please fix the mouse code too... ;-)
>> >
>> > It's kindof funny you mention this..  For about 2 years now these
>> > very same problems have irritated me.  The XFree86 X server mouse
>> > acceleration code is horribly obsolete and doesn't handle current
>> > needs very well at all.  The problem is actually several
>> > different problems, all of which I have done some research on and
>> > poked around a bit with.
>> >
>> > 1) The X and Y axis are accelerated individually, which is kindof
>> > a broken way to do it, because we don't think or use the mouse in
>> > terms of X and Y axis, but instead in terms of a direction and
>> > velocity.  IMHO, proper mouse acceleration should be based upon a
>> > vector and an acceleration factor.
>> >
>> > 2) The X acceleration is very lame.  Basically, it monitors the
>> > current velocity of the mouse input, in each axis separately, and
>> > once the velocity on a given axis exceeds a given threshhold, it
>> > applies a fixed acceleration factor to it.  While both the
>> > threshhold and the accel factor are user defineable, they do not
>> > really let the user configure what they want to configure.  In
>> > order to get reasonable on screen velocity of the pointer, the
>> > user must use acceleration even if they don't want it, just to
>> > get decent mouse pointer speed.  That sucks.  Also, as the mouse
>> > crosses the threshhold they wont perfectly cross it only once,
>> > but rather random velocity speed ups and slow downs which are
>> > normal when moving a mouse, will cause the threshhold to be
>> > crossed back and forth many times.  This results in a mouse
>> > pointer that is very jerky and jumps around annoyingly.  Yuck!
>> > ;o)
>> >
>> > 3) Lack of ability to control fine grained mouse movement at the
>> > pixel level when moving the mouse slowly.  Generally you have to
>> > set the accel and threshhold to a point that it is fast enough,
>> > but then can't pick individual pixels.  That sucks for doing
>> > artwork and other things like you describe.
>> >
>> > 4) Mouse pointer speed should be independant of the physical
>> > screen resolution.  Moving the mouse an inch on your mousepad,
>> > should move it n inches on the screen, not n pixels.  It sucks to
>> > have to reconfigure your mouse when you change video resolution
>> > in order to get the same mouse pointer speed.
>> >
>> > What is greatly needed, is for the X and Y axis separate
>> > acceleration to go away completely, and instead for acceleration
>> > to occur based on a direction vector and velocity which is the
>> > result of the movement of both the X and Y axis.  That is simple
>> > to implement in the code, but I dunno what all X legacy garbage
>> > it would break when certain applications try to reprogram the
>> > mouse acceleration using existing semantics.  Implementing it in
>> > a safe way for legacy apps might prove more difficult.  Doing
>> > acceleration with a direction vector would provide less jerky
>> > acceleration in particular when moving on diagonals.  If you move
>> > the mouse in a perfect circle currently, mouse movement on screen
>> > will be a rounded square.  With my method, you'll get an on
>> > screen circle.  This solves problem #1 above.
>> >
>> > Problem #2 can be solved by taking the acceleration curve which
>> > currently has 2 points (unaccelerated, and when the threshold is
>> > crossed - accelerated), and making it have more than just 2
>> > points.  It should have 4 or 5 points.  When the mouse is moving
>> > really slow, it should move on screen slow.  As acceleration
>> > increases, threshhold point 1 can be crossed, and a slight
>> > acceleration factor applied, if the velocity increases,
>> > thresshold 2 gets crossed, and another higher accel factor
>> > applied, etc. for 4 or 5 ranges.  This would provide a much
>> > smoother and gradual acceleration, rather than the XFree86 ugly
>> > jerky acceleration present forever.  Another improvement upon
>> > this is for the threshhold crossings to be in different locations
>> > on increases in velocity than they are upon decrease of velocity.
>> >
>> > That way if the mouse velocity is increasing and crosses an
>> > upswing threshhold, it bumps to the next acceleration factor,
>> > however if a slight slowdown in velocity occurs, the same
>> > threshhold doesn't get crossed thus making the XFree86 jerky
>> > style accel that occurs on threshhold boundaries.  Instead, we
>> > would have the slowdown accel thressholds be offset enough below
>> > the speedup accel threshholds that normal mouse movement would
>> > probably never hit conditions where a single threshhold gets
>> > alternately crossed when a user moves the mouse at a near linear
>> > velocity that happens to be right center on a threshhold point.
>> > I just came up with this nifty idea while writing this reply to
>> > you.  Thanks for the inspiration.  ;o)
>> >
>> > It would also be possible to make each of these threshhold/accel
>> > factor sets user configureable, and also allow switching between
>> > different sets for different tasks.  In simple GUI terms, GNOME
>> > or whatever could have say 5-10 preprogrammed accel sets, and
>> > present the user with a simple nobrainer slider called "Mouse
>> > speed" or "Mouse acceleration", with no other complicated
>> > controls.  As the user moves it from left to right, they pass
>> > through say 10 levels of acceleration.  Each of those levels
>> > selects a new acceleration set, which consists of say 5
>> > threshhold point/acceleration factor pairs, with each set
>> > increasing in acceleration at each point, and non-linearly.
>> >
>> > This would provide IMHO the smoothest acceleration and get rid of
>> > the jerkies forever, bringing X into the 21st century.  ;o)
>> >
>> > I think I could code something like this in less than a week,
>> > that would work great, but probably break tonnes of X protocol
>> > rules and legacy applications and other garbage.  ;o)  The
>> > problem is, implementing all this stuff in a way that doesn't
>> > break all known apps out there that try to set the currently
>> > braindead mouse acceleration.
>> >
>> > All of this of course applies to the XFree86 X server itself, I'm
>> > not at all sure how the kdrive X server deals with this stuff.  I
>> > presume the problem is similar in the kdrive server though too,
>> > and so it might be possible to solve the problem in kdrive
>> > experimentally first.
>> >
>> > Another problem, is synchronization of the mouse pointer screen
>> > updates, to the refresh rate of the monitor.  That provides
>> > a smoother looking mouse.
>> >
>> > This problem is IMHO something that would be very interesting and
>> > fun to solve.  I'd love to work on it, and I've already dipped my
>> > fingers into it over a year ago, but then realized all kinds of
>> > junk would break and need legacy stuff to fix, or some new X
>> > extensions or Xinput stuff, and then I lost interest due to the
>> > growing complexity.  If I can find the time to investigate it
>> > further though, I'd love to solve this problem for good in X
>> > land, and perhaps drag other people into getting involved doing
>> > the stuff I find ugly and perhaps boring.  ;o)
>> >
>> > I'm kindof glad you sent us this email, as it's resparked my
>> > interest in this problem.  Maybe I can convince my manager to let
>> > me do this as a work sponsored project even...  ;o)
>> >
>> > Thanks for your feedback!
>> >
>> > Take care,
>> > TTYL
>> -- 
>> Jim Gettys <Jim.Gettys@hp.com>
>> HP Labs, Cambridge Research Laboratory
>>

Actions: View

Attachments on bug 138: 68

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.