Bug 90614
Summary: | xemacs displays the wrong X cursor | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Ian Peters <itp> |
Component: | XFree86 | Assignee: | X/OpenGL Maintenance List <xgl-maint> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | garrett, jansen, petersen, rh-bugzilla |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-12 13:16:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ian Peters
2003-05-11 03:36:06 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. 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 it, etc. 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. TIA 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 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 order perhaps? 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. 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 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! 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. |