Bug 505326
| Summary: | Mouse's "background" is hosed with dual-screen | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Robert Peterson <rpeterso> | ||||
| Component: | xorg-x11 | Assignee: | Peter Hutterer <peter.hutterer> | ||||
| Status: | CLOSED CANTFIX | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 11 | CC: | mcepl | ||||
| 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: | 2009-06-11 14:40:59 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: | |||||||
| Attachments: |
|
||||||
Thanks for the report. I am really sorry but we cannot help you with your problem, as we are not able to support binary-only drivers. If you would be able to reproduce this issue using only open source software, please, reopen this bug and attach /var/log/Xorg.0.log, /var/log/dmesg, and /etc/X11/xorg.conf (if you have any), but in meantime I have no choice than to close this bug as CANTFIX (because we really cannot fix it). The open source 'nouveau' driver (in package xorg-x11-drv-nouveau) is the recommended alternative for users of Nvidia graphic chips. It is used by default in Fedora 11 and later if you remove any customizations that explicitly set the video driver. The older "nv" driver may be needed in some cases. It is also available in older Fedora releases. Install the packages xorg-x11-drv-nouveau or xorg-x11-drv-nv and override the X server's default choice if necessary. See https://fedoraproject.org/wiki/Features/NouveauAsDefault for more information. If you used a non-packaged version of the driver from the Nvidia website please clean your system from additional libraries and software it installed. For users who are experiencing problems installing, configuring, or using the unsupported 3rd party proprietary "nvidia" video driver, Nvidia provides indirect customer support via an online web based support forum. Nvidia monitors these web forums for commonly reported problems and passes them on to Nvidia engineers for investigation. Once they've isolated a particular problem, it is often fixed in a future video driver update. The NVNews Nvidia Linux driver forum is located at: http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14 Once you have reported this issue in the Nvidia web forums, others who may have experienced the particular problem may be able to assist. If there is a real bug occuring, Nvidia will be able to determine this, and will likely resolve the issue in a future driver update for the operating system releases that they officially support. While we does not support the proprietary nvidia driver, users requiring technical support may also find the various X.Org, XFree86, and Red Hat/Fedora mailing lists helpful in finding assistance: X.Org mailing lists: http://www.freedesktop.org/XOrg/XorgMailingLists XFree86 mailing lists: http://www.xfree86.org/sos/lists.html Red Hat/Fedora mailing lists: https://listman.redhat.com/mailman/listinfo >The open source 'nouveau' driver (in package xorg-x11-drv-nouveau) >is the recommended alternative for users of Nvidia graphic chips. I would love to go to the nouveau driver, however: Excerpt from my original problem description: >(I could not get this video card to work properly on F11 unless >I used the vesa driver, which is bogus, thus I was forced to the >proprietary driver). Again, I reiterate that I cannot go to the nouveau or nv drivers because they DO NOT WORK with my hardware in F11, even with a single monitor configuration. I scratch built the system to get rid of any proprietary drivers. I had to use "vesa" because anaconda froze up if I took the default. An "Xorg -configure" later generated a xorg.conf.new file with the "nv" driver, which you're saying is not the "recommended" one. I switched it to the nouveau driver by hand and the only useful information the log file would give me was this: (!!) NOUVEAU(0): Raw DCB entry 0: 02000300 00000028 (!!) NOUVEAU(0): Raw DCB entry 1: 01000302 00020030 (!!) NOUVEAU(0): Raw DCB entry 2: 04011310 00000028 (!!) NOUVEAU(0): Raw DCB entry 3: 02011312 00000030 (!!) NOUVEAU(0): Raw DCB entry 4: 010223f1 00c0c080 (--) NOUVEAU(0): Parsing VBIOS init table 0 at offset 0xCE32 (EE) NOUVEAU(0): ========== unknown reg 0x00021358 ========== (EE) NOUVEAU(0): ========== unknown reg 0x00021220 ========== (EE) NOUVEAU(0): ========== unknown reg 0x0002121C ========== (EE) NOUVEAU(0): 0xCF47: Init table command not found: 0x97 (--) NOUVEAU(0): Parsing VBIOS init table 1 at offset 0xD21B (--) NOUVEAU(0): Parsing VBIOS init table 2 at offset 0xE176 (--) NOUVEAU(0): Parsing VBIOS init table 3 at offset 0xE2A5 (--) NOUVEAU(0): Parsing VBIOS init table 4 at offset 0xE4B5 (II) NOUVEAU(0): NV50DispPreInit is called. (WW) NOUVEAU(0): DCB encoder type 1 not known and later: (II) AIGLX: Screen 0 is not DRI2 capable drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 13, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 13, (OK) drmOpenByBusid: drmOpenMinor returns 13 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) AIGLX error: dlopen of /usr/lib64/dri/nouveau_dri.so failed (/usr/lib64/dri/nouveau_dri.so: cannot open shared object file: No such file or directory) (II) AIGLX: reverting to software rendering (II) AIGLX: Loaded and initialized /usr/lib64/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) NOUVEAU(0): Setting screen physical size to 376 x 301 (WW) NOUVEAU(0): NV50CheckWriteVClk() timed out. (II) NOUVEAU(0): A reboot is probably required now. An "lspci" command tells me this about my video card: 01:00.0 VGA compatible controller: nVidia Corporation G94 [GeForce 9600 GT] (rev a1) I see there are about 30 bug records opened that include "nouveau" in the comment, so it sounds like I'm using F10 until the driver gets fixed. |
Created attachment 347401 [details] The xorg.conf I'm using (that worked on F10). Description of problem: I just upgraded my box to F11, current as of today. Everything was working perfectly in F10 with the same hardware. I have two monitors, each of which has a different resolution. The primary display is 1920x1200 and the secondary is 1280x1024. I am using the nvidia proprietary driver and my graphics card, according to lspci is: "nVidia Corporation G94 [GeForce 9600 GT] (rev a1)" (I could not get this video card to work properly on F11 unless I used the vesa driver, which is bogus, thus I was forced to the proprietary driver). The problem is that when I move my cursor from one display to the other, my mouse's "background" is painted incorrectly. The background of the mouse (tracks with the mouse movement) appears as a square pixel-for-pixel copy of what's on that display at 0:0. The mouse cursor itself paints correctly and appears as an arrow. If I drag a window from monitor0 to monitor1, the window paints correctly there, however, the mouse that I'm dragging picks up the corruption from 0:0 as soon as it hits monitor1 and that portion of the screen that contains the mouse cursor now has the block appearing at 0:0. If I open a new window in monitor1, (e.g., by using nautilus-open- terminal to right-click and open a terminal session) then the cursor is fixed in monitor1, and tracks properly there. However, if I move my cursor back over to monitor0 again, now the cursor becomes corrupted with the contents of monitor0 at 0:0. Again, I can fix the cursor by opening another window there. So it seems as if some setting relating to the mouse cursor is not being copied properly when I move from display to display. Version-Release number of selected component (if applicable): F11 current as of 2009 June 11. How reproducible: Always Steps to Reproduce: 1. Move cursor from one screen to the other Actual results: Cursor smears a 20x30 or so block of graphics that looks like 0:0 across the screen, corrupting the screen contents. Expected results: The cursor should be painted normally and preserve the screen contents. Additional info: