From eugenia@osnews.com Wed Nov 5 15:08:40 2003 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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" To: "Jim Gettys" , "Mike A. Harris" Cc: "Keith Packard" References: <01f101c3a340$3425e900$0a00000a@eugenia> <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" To: "Mike A. Harris" Cc: "Eugenia Loli-Queru" ; "Keith Packard" 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 > HP Labs, Cambridge Research Laboratory >