Bug 25036 - KMS + multihead leaves ghost mouse pointer
Summary: KMS + multihead leaves ghost mouse pointer
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL: http://bbs.archlinux.org/viewtopic.ph...
Depends on:
Reported: 2009-11-11 07:57 UTC by ataraxia937
Modified: 2011-03-07 09:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description ataraxia937 2009-11-11 07:57:21 UTC
I'm running a November 1st snapshot build of both the DDX and DRM modules, as provided by Arch Linux. Hardware is a GeForce 9400 GT. There are two monitors attached, configured via RandR. I don't have any options set in xorg.conf other than the RandR setup.

When I move my mouse from one screen to the other, a "ghost pointer" is left behind in the last place on the now-inactive screen that the pointer was drawn. It remains there until I enter that screen again. While it is there, the cursor glyph updates in sync with the "real" pointer on the active screen.

If I move the mouse slowly enough that the cursor visually reaches the edge of the screen before I cross to the other screen, the ghost won't appear until the glyph changes, at which point the ghost suddenly appears, mapped on the edgemost column of the screen. It then remains there and behaves just as in the previous case.

There are no interesting log messages from either the DDX or the DRM.

This bug only occurs with KMS enabled.

This resembles bug 12471, except that there, the ghost is always in the top-left corner.

The URL attached to this bug is to a thread on the Arch Forums describing this bug.
Comment 1 Francis Galiegue 2010-01-18 07:14:06 UTC
I confirm the bug, I observe the same here. My card is reported as such by lspci:

01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8500 GT] (rev a1)

(lspci reports: 01:00.0 0300: 10de:0421 (rev a1))

I use git libdrm and xf86-video-nouveau. This is a Gentoo unstable amd64 machine.

I boot with drm.debug=6 and I notice that there is a sequence of calls as this:

* nv50_cursor_set_offset;
* nv50_cursor_show;
* this last sequence repeated many times;
* then nv50_cursor_hide.

But when the bug appears, the nv50_cursor_hide show is nowhere to be seen.
Comment 2 Francis Galiegue 2010-01-19 02:09:42 UTC
I should also comment that the bug only appears when there's some sort of cursor state change, which happens pretty much every time you change widget in a window.

That is, it will not appear if you have no window displayed and just move the cursor between the different desktops.

The kernel messages I mentioned above appear pretty much every time I cross window borders, enter/exit a text editing area, etc etc.
Comment 3 ataraxia937 2010-02-18 19:17:52 UTC
This is fixed for me as now.
Comment 4 Andreas Radke 2010-02-19 01:33:03 UTC
what change/update fixed it for you? I'm still having the cursor hanging on the screen border. mostly when I move the mouse quickly. it doesn't happen when I move the mouse slowly.
Comment 5 ataraxia937 2010-02-19 06:06:44 UTC
I don't know what change fixed it, as I haven't been tracking it, and haven't done a bisect either. I've been using your [extra] packages until now. Not surprisingly, moving libdrm 2.4.18-2 and reverting to your nouveau packages makes the bug show again. I'm content to wait for the next [extra] update (which I expect will be after kernel 2.6.33).

(Upstream folks, sorry about the Arch-specific spam here...)
Comment 6 Xavier 2010-02-19 06:49:41 UTC
16:10 < shining> iirc curro_ said the pointer/cursor bugs would be fixed by this : http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=0917665d1f2f1e76b6a0e7a4c027512f9f45f41b
16:15 < curro_> yeah that fixed it
Comment 7 Marcin Slusarz 2011-03-07 09:52:33 UTC
It seems to be fixed, so I'm closing this bug report.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.