Bug 505326 - Mouse's "background" is hosed with dual-screen
Mouse's "background" is hosed with dual-screen
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Peter Hutterer
Depends On:
  Show dependency treegraph
Reported: 2009-06-11 10:05 EDT by Robert Peterson
Modified: 2009-06-17 08:03 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-11 10:40:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The xorg.conf I'm using (that worked on F10). (4.00 KB, text/plain)
2009-06-11 10:05 EDT, Robert Peterson
no flags Details

  None (edit)
Description Robert Peterson 2009-06-11 10:05:28 EDT
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:

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:
Comment 1 Matěj Cepl 2009-06-11 10:40:59 EDT
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:


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:

XFree86 mailing lists:

Red Hat/Fedora mailing lists:
Comment 2 Robert Peterson 2009-06-17 08:03:52 EDT
>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.

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