Red Hat Bugzilla – Bug 83284
(Mach64) Mouse cursor visual glitches with XFree86
Last modified: 2007-04-18 12:50:33 EDT
Description of problem:
I have upgraded my Phoebe2 system to the latest XFree86 packages from RawHide
(they were XFree86-4.2.99-4.20030129 at that moment) and I have noticed some
visual glitches with my mouse cursor when it changes its shape. The visual
glitch is hard to describe: basically, when the mouse shape is changed (from an
arrow to the I-box, for example, or when you hover over a window resize handle),
for a very short period, the mouse is shown as a big 32x32 (I think) mess of
vertical lines of different thickness, and then, it returns to its normal
It doesn't seem a driver problem, since in XFree86-18.104.22.168-20030115.0 this
problem is not present. Also, this is mainly a visual problem since the mouse
cursor is drawn incorrectly for a few microseconds.
My video card is an ATI Rage Mobility M1 AGP 8MB using the Gatos SourceForge ATI
4.2.0 and 4.3.0 (experimental) video driver with XV support.
I have had to downgrade to XFree86-22.214.171.124-20030115.0 since this visual effect
is disgusting for me.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Phoebe2 onto a computer with an ATI Rage Mobility M! (or Mach64)
video card or similar.
2. Upgrade to XFree86-4.2.99-4.20030129 from RawHide
3. Get the Gatos ATI.2 video driver from http://gatos.sourceforge.net and
4. Launch X
5. Make the cursor shape change by hovering the mouse cursor over a window
resize handle, for example. Sometimes, the visual glitch described is shown.
The mouse cursor looks strange during transition of mouse cursor shape.
Mouse cursor should always be drawn correctly, as in previous versions of XFree86
Phoebe2 clean install doesn't exhibit this hehaviour. However, upgrading to a
newer XFree86 version using up2date, or manually from RawHide, makes this show.
It seems a problem with new mouse cursor handling, as mouse cursors also look
different in RawHide (for example, Mozilla uses a combined arrow-hourglass mouse
cursor while downloading Web pages).
*** This bug has been marked as a duplicate of 82997 ***
This bug is _NOT_ a duplicate of 82997. Bug 82997 is broken hardware
mouse cursor code on SiS chipsets. This bug is Radeon hardware cursor
is affected by Xcursor code changes. 2 separate issues.
I just noticed that you are using the GATOS drivers. Red Hat obviously
does not ship GATOS drivers and is not responsible for problems encountered
while using the GATOS drivers.
However, the XFree86 driver which is supplied in rawhide also has this
mouse cursor problem. Please however do not file bug reports against
XFree86 if you're using GATOS drivers or drivers from anywhere else than
what is supplied by Red Hat, unless you can reproduce it with Red Hat
supplied drivers after a fresh reboot (to hardware reset the card to power
I'm leaving this open as I know our drivers also have this problem. There
is a fix or workaround just about ready for testing, but of course you'll
have to use the Red Hat supplied driver in order to test it. The GATOS
author might be interested in it though as well if it works out, so once
I'm sure it works, I will contact him too, so he can fix the GATOS driver
When I reported this bug, I didn't said I had an ATI Radeon video card, but a
Mach64-based ATI RAGE Mobility M1 AGP...
So, I don't understand why Radeon keyword has been added to the summary :-?
Oops... because I'm dumb. ;o)
Please attach your X server log and config file.
Created attachment 89923 [details]
This is my XF86Config file... It's the same no matter whether I'm using the
stock XFree86 ATI Mach64 driver or the GATOS video driver (the GATOS video
driver replaces the ati_drv.o module so no changes to XFree are needed).
I can' currently supply the XFree86 server log as I have downgraded to the
original XFree86 package that came with Phoebe2, and not using the one from
RawHide. If you don't mind, I prefer to wait for a new release of the GATOS
ATI.2 video driver (which will be released soon AFAIK) and then try to reproduce
with the latest XFree86 release at the moment (RawHide).
No problem. That just means this is more unlikely to get fixed
for 4.3.0. ;o)
I'm still experiencing this behavior with XFree86-126.96.36.1991-20030203.1 using
both stock ATI driver and GATOS ATI.2 (4.3.0 experimental 4) driver. I will
attach my X server log.
Created attachment 89925 [details]
sever log when using GATOS ATI.2 driver
Curiously, when using Rawhide's XFree86-188.8.131.521-20030205, it seems the mouse
cursor visual glitch does not happen when changing from a certain cursor shape
to another: for example, when changing from the standard black pointer arrow to
Mozilla's new hand shape that is shown when the mouse hovers over a link, I'm
unable to reproduce the visual glitch. It seems the transition is smooth and no
strange artifacts are drawn on the screen (at least, I can't appreciate them).
However, when the mouse shape changes between the black pointer arrow and the
I-box cursor (the one that is shown when the mouse is over most text edit
controls) or the window resize cursor (north-south or west-east), the visual
glitch can still be seen.
I'm also able to reproduce the mouse cursor visual glitch when using stock
XFree86 ATI video driver. I removed the GATOS video driver, then upgraded to
XFree86-184.108.40.2061-20030206.0. However, I still have the mouse cursor
problem,easily reproducible by forcing a mouse cursor shape transition between
I-beam (or whatever you call the mouse cursor displayed on text controls) and
the standard arrow.
A bugfix for this has been committed to XFree86 CVS. I am updating my
sources, and will be releasing a new build within 12 hours.
I'm still experiencing this issue with XFree86-220.127.116.111-20030212.
sorry, my build was completed in 12 hours, but didn't get anywhere public
in 12 hours.
XFree86-18.104.22.1681-20030213.1 should fix this. It's at:
Please test and resolve bug as RAWHIDE or ASSIGNED.
OK, your XFree86-22.214.171.1241-20030213.1 package fixed this for me.
I'm closing this bug as fixed in RawHide right now. Thanks!