On Mon, 2004-06-28 at 15:09 -0400, Chris Metzler wrote: > > I recently upgraded X to the version currently in sarge > (4.3.0.dfsg.1-4). Since then, in various 3D apps (e.g. blender, > flightgear, bzflag), I've been seeing some very odd behavior related > to the mouse cursor. > > So long as the mouse is not moved, everything is fine. However, if > the mouse cursor is moved, it flickers at high frequency. Also, quite > often, a small rectangular off-colored patch appears at the location > where the mouse cursor started. Typically, the color of that patch is > that of whatever background the application would be writing upon. No > other distortion appears along the path the mouse moves, nor at the > mouse cursor's final destination. Subsequent screen updates > (e.g. because of movement of the aircraft in flightgear) correct the > bogus region, so the distortion is transient. However, in software > where the mouse gets moved a lot, or where the screen isn't being > continuously updated, this can make the screen extremely difficult to > read.
[...] > This behavior has occurred in every GL application I've checked which > uses the default X mouse cursor (the above, openuniverse, tuxracer > under the "Oliver's Math Class" course). However, it does *not* occur > with several other 3D apps I tried (tuxracer, gl-117, criticalmass). > These apps are noteable in that they use a different (much larger) > mouse cursor; but I have no idea whether this correlation implies > anything significant. Those apps probably don't use the X cursor at all but draw it themselves with OpenGL. This sounds like a duplicate of bug #254257; if anything, it's a bug in the X 2D drivers that they don't force hardware cursors on direct-rendered windows. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
