Bug 90614 - xemacs displays the wrong X cursor
Summary: xemacs displays the wrong X cursor
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-11 03:36 UTC by Ian Peters
Modified: 2007-04-18 16:53 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-12 13:16:23 UTC
Embargoed:


Attachments (Terms of Use)

Description Ian Peters 2003-05-11 03:36:06 UTC
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):
21.4.12-6

How reproducible:
always

Steps to Reproduce:
1. start xemacs in X
2. move the mouse over the xemacs window
3. observe problem
    
Actual results:
XC_ul_angle, or GDK_UL_ANGLE, cursor

Expected results:
XC_xterm, or GDK_XTERM, cursor

Comment 1 Ian Peters 2003-05-11 03:38:32 UTC
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.

Comment 2 Jens Petersen 2003-05-12 13:04:58 UTC
Does the wrong cursor go away if you move it around a bit inside
the XEmacs window?

Comment 3 Ian Peters 2003-05-12 13:23:27 UTC
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
it, etc.

Comment 4 Enrico Scholz 2003-05-20 10:13:33 UTC
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.

Comment 5 Ian Peters 2003-05-22 13:42:22 UTC
Indeed; my machine is using a GeForce 3 with the nv driver as well.

Comment 6 Jens Petersen 2003-05-22 21:45:13 UTC
Come to think of it, I think I've only seen this with an nv card too. :-\

Ok, re-assigning to XFree86, fwiw.

Comment 8 Tobias Ringstrom 2003-08-28 09:46:04 UTC
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.

Comment 9 Tobias Ringstrom 2003-08-28 10:35:23 UTC
A workaround is to add the following line to the appropriate Device section (the
one with the nv driver):

        Option      "HWCursor" "off"


Comment 10 Mike A. Harris 2003-08-30 10:05:29 UTC
Please attach your X server config file and log file from a configuration
in which the problem occurs, so I can attempt to reproduce.

TIA

Comment 13 Mike A. Harris 2003-09-02 08:19:41 UTC
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.

TIA

Comment 14 Ian Peters 2003-09-05 04:59:19 UTC
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.

Comment 15 Mike A. Harris 2003-09-05 16:38:54 UTC
Garrett) Is it possible that our bluecurve theme has cursors in the wrong
order perhaps?

Comment 16 Need Real Name 2003-11-25 00:39:35 UTC
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:

Emacs.default.attributeBackground:      #000000

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.



Comment 17 David Jansen 2003-12-17 09:24:56 UTC
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.

Comment 18 Mike A. Harris 2003-12-17 10:52:14 UTC
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.

Comment 19 Pierre Demartines 2004-01-07 16:11:45 UTC
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
xemacs, etc.

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!

Comment 20 Mike A. Harris 2004-10-12 13:16:23 UTC
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:

        http://fedora.redhat.com/download

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"
component.

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.


Note You need to log in before you can comment on or make changes to this bug.