Bug 80255 - Garbage around mouse pointer if setpointer is used with 2 cards and compositing
Summary: Garbage around mouse pointer if setpointer is used with 2 cards and compositing
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.2 (2007.02)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-19 22:08 UTC by Bernardo Donadio
Modified: 2019-11-19 07:47 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Photo of the artifact on VirtualBox with Guest Additions (37.13 KB, image/jpeg)
2014-06-19 22:08 UTC, Bernardo Donadio
no flags Details
Xorg.0.log (81.22 KB, text/plain)
2014-06-20 03:30 UTC, Bernardo Donadio
no flags Details
dmesg (77.25 KB, text/plain)
2014-06-20 03:31 UTC, Bernardo Donadio
no flags Details
xrandr --verbose output (19.80 KB, text/plain)
2014-06-20 09:58 UTC, Bernardo Donadio
no flags Details

Description Bernardo Donadio 2014-06-19 22:08:43 UTC
Created attachment 101387 [details]
Photo of the artifact on VirtualBox with Guest Additions

A square of garbage (made of old drawings of the screen) is drawn around the mouse pointer if the client software tries to use setpointer (I think).

Reproducible if two radeon cards (RS780 and RV770) are used at the same time to extend the desktop *and* there's a compositing window manager being used (KDE and GNOME have the problem, OpenBox does not).

So far I could see the problem with:
* Firefox when showing a big image (like this one: http://upload.wikimedia.org/wikipedia/commons/3/36/Axis_axis_%28Nagarhole%2C_2010%29.jpg which requires the mouse pointer to be changed to a zoom-in/out magnifier icon)
* VirtualBox when using Guest Additions (seamless pointer integration)
* rdesktop-vrdp always

I'm using xorg-x11-server-Xorg 1.14.4-9.fc20, with kernels 3.14-3.16 (already tried all three), and xorg-x11-drv-ati 7.2.0 (3.20131101git3b38701.fc20).

Will attach a photo of the glitch.
Comment 1 Alex Deucher 2014-06-20 01:44:35 UTC
Please attach your Xorg log and dmesg output.
Comment 2 Bernardo Donadio 2014-06-20 03:30:13 UTC
Created attachment 101392 [details]
Xorg.0.log

Xorg.0.log just after trigerring the issue (no relevant data)
Comment 3 Bernardo Donadio 2014-06-20 03:31:22 UTC
Created attachment 101393 [details]
dmesg

dmesg output just after triggering the issue (also no relevant data)
Comment 4 Bernardo Donadio 2014-06-20 08:14:30 UTC
Just noticed: also reproducible in Wolfram Mathematica 9, when it tries to use a non-standard mouse icon.

It's definetely a problem at the mouse icon overlay.
Comment 5 Michel Dänzer 2014-06-20 09:54:41 UTC
The attached photo looks more like a software rendered cursor gone wrong though.

How does the garbage behave when you move the mouse?

Please also attach the output of xrandr --verbose.
Comment 6 Bernardo Donadio 2014-06-20 09:58:18 UTC
Created attachment 101424 [details]
xrandr --verbose output
Comment 7 Bernardo Donadio 2014-06-20 10:05:15 UTC
The garbage is made of past renderings of the screen (normally the window beneath the current window), plus all past drawings of the cursor icon (they get stacked up, just like there's a "trail" of drawings). However, this garbage only appears inside the square, in the part that is not filled by the current cursor.

The square is always placed exactly around the cursor. If I move the mouse a bit to the side, it restores the current window drawing at the portion that is not covered by the garbage square.

It's looks like there's a "mask" around the pointer, which gets filled with past drawings.
Comment 8 Bernardo Donadio 2014-06-20 10:30:46 UTC
Here's a short video of the issue, this time on rdesktop-vrdp: https://www.youtube.com/watch?v=exNyrj4klwA
Comment 9 Michel Dänzer 2014-06-23 06:36:34 UTC
Dave Airlie confirmed on IRC that PRIME currently doesn't support HW cursors in this scenario. He suspects this issue is due to some lack of flushing / synchronization between the GPUs.
Comment 10 Bernardo Donadio 2014-06-24 01:12:22 UTC
Is there any possible workaround?
Comment 11 Martin Peres 2019-11-19 07:47:17 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/107.


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.