Description of problem:
When the mouse is over an XEmacs window, the mouse cursor becomes a top left
corner (XC_ul_angle, or GDK_UL_ANGLE), and isn't reset until you move the mouse
over another window that has set the cursor (such as a terminal) and then back off.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start xemacs in X
2. move the mouse over the xemacs window
3. observe problem
XC_ul_angle, or GDK_UL_ANGLE, cursor
XC_xterm, or GDK_XTERM, cursor
retesting, you may have to move the mouse in and out of the xemacs window a few
times, and/or switch desktops to and from the desktop with xemacs (with the
mouse over the xemacs window) to see the bug.
Also, this didn't happen in previous RHL releases.
Does the wrong cursor go away if you move it around a bit inside
the XEmacs window?
Yes; also, I'm much more likely to see the wrong cursor if I'm moving over a
relatively empty buffer (think *scratch* just after starting xemacs) than over
something I've been working on for a while, but this isn't always true.
Also, for completeness, today I'm seeing a variety of incorrect cursors over
xemacs, including an inverted pointing hand, an upper-left angle with a cross in
May be caused by XFree86 also. I see it with the 'nv' driver on some GeForce
cards, but with a Matrox MGA450 or an old Riva TNT the cursors are fine.
Indeed; my machine is using a GeForce 3 with the nv driver as well.
Come to think of it, I think I've only seen this with an nv card too. :-\
Ok, re-assigning to XFree86, fwiw.
A possibly useful piece of info is that the cursor is only broken if the
background of emacs is changed from the default, i.e. if an X resource is set,
or if emacs is started with 'emacs -bg NavajoWhite' (or any other color).
I see this on two computers with (different) Nvidia cards, but not on a computer
with a Radeon. All of them are RHL9 of course.
A workaround is to add the following line to the appropriate Device section (the
one with the nv driver):
Option "HWCursor" "off"
Please attach your X server config file and log file from a configuration
in which the problem occurs, so I can attempt to reproduce.
I have 2 Nvidia cards available to me for testing purposes, a Quadro 4 XGL 900,
and a Quadro 2, both AGP. If the original reporter could please confirm
wether or not the solution suggested above:
Option "HWCursor" "off"
... makes the problem go away while using the Red Hat supplied "nv" driver,
I can set up one of the Nvidia cards and try to determine the cause of the
problem locally. I believe this problem is caused by a broken Xcursor
cursor theme. Please indicate which Xcursor theme you are using as well.
Turning off the hardware cursor gets rid of the problem for me, although the
software cursor is sub-par overall in terms of responsiveness, etc.
The Xcursor theme is the default Bluecurve theme.
Garrett) Is it possible that our bluecurve theme has cursors in the wrong
I have been seeing the same problem with emacs windows (I don't use
xemacs). I can confirm that the problem only occurs after changing the
background color of emacs from the default white color to any other
color. In particular, the bug seems to be triggered by the following
line in my .Xdefaults file:
This is on a computer with an NVIDIA GeForce 2 MX card, using the nv
driver. Adding the suggested 'Option "HWCursor" "off"' line to the
videocard0 device in /etc/X11/XF86Config, and then restarting the X
server by hitting "<ctrl> <alt> <backspace>", has resolved the problem.
For what it's worth, I see the problem too with other X (not
gnome/KDE) applications, especially old ones compiled with a previous
version of RHL (currently running FC1) and 3rd party applications.
Ok, I'm investigating this now. If I can't see anything obvious,
I'll disable hardware cursor support in the nv driver, since that
seems to work for everyone so far, and the problem seems isolated
to that one driver, which implies it is driver related.
I had the same problem in xterm (in addition to xemacs), but only
after changing the background color (XTerm.*.background). I've also
observed some strange cursor timeout behaviors:
moving the cursor from an xterm back into the xemacs would "uglify"
the cursor, "but not always" (don't we all love that kind of bug
description?...) It seems related to the amount of time spent in the
xterm before moving the cursor back in the xemacs.
Additionally, the type of ugly cursor (big low-res outlined X cursor,
or inverted outlined hand --especially after using xpdf...) that a
window would eventually settle for depends on the speed&trajectory of
the mouse (i.e. which underlying windows see the cursor): moving from
xterm to xemacs has different outcome than moving from desktop to
One last piece of information: even several days after not using xpdf
(which I believe started the "hand" cursors in my xterms), I would
keep getting that hand cursor in xterm.
Many thanks to Tobias Ringstrom for the 'Option "HWCursor" "off"' --it
fixed all these cursor problems!
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue. Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:
If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.