Multi monitor setup with Radeon
I have been using the Open Source driver pretty much since I bought this laptop. It sports the RV690 chipset which AFAIK is actually based on the R500 ASICS. For the longest time having a multiple monitor setup in this system has been problematic, to say the least, but in recent incarnations of both the driver and the Xorg server it has been progressively easier to reasonably achieve this goal. Especially useful in a laptop/netbook for presentations and the like.
At any rate, there is still a long standing problem with multiple monitors setup and the Radeon driver (in it current incarnation in Fedora 14, at least), especially when running with Compiz. On the secondary display the background image is only displayed up to half of the screen, with a drop shadow and the rest of the display is covered with whatever is left lingering at that area.
As they say, an image speaks a thousand words: Radeon Bug
What makes you think it's a radeon bug?
Is it possible you're hitting the texture size limit of the GPU there? Can't really discern your resolution from a scaled screenshot..
RS690 is basically 6xx display hardware with 4xx 3D engine, so I think the texture limits (of the 3D engine) would be in the ballpark of 2048x2048 or 2560x2560 (I forget which). If your total screen width is greater than the texture limit you're going to have a problem unless Compiz uses multiple draw operations to cover the screen. I thought I remembered hearing about a Compiz patch or version which did that but that was maybe a year ago and I haven't seen anything since.
What is the resolution of each of your displays ? Looks like the display on the right is over 2k horizontal by itself, so it's almost definite that your two screens together are blowing over the texture limit.
First of all, thank you both for replying.
The screen resolution is 2960x1050, which indeed in either case 2048 or 2560 px max texture size would be beyond the limits of the hardware... However I also do see this with standard resolution projectors (1024px or 800px width) which would yield the maximum resolution of 2080 or 2304, which indeed makes me think the maximum texture resolution of this hardware is in the 2048px range. That should be why I'm getting this "artifact", simply hardware maxed-out. Thank you both.
Now, I'll go see if I can get my hands on the patched version of Compiz.
The screen is composed of the laptop's 1280x800 and an external monitor with 1680x1050 (2960x1050)
Sounds good. I should stress that I`m not completely sure the patch even exists, just that I think I remember hearing about it.
Another way around the problem is to position the second output above or below the internal screen, thus getting something like 1680x1850. It'll take some brain adjusting to move the mouse over the correct screen edge though.
You could also try setting up zaphod + xinerama, but that's more trouble than it's worth.
Better try finding those mythical compiz patches first
The max texture size is 2048x2048. xrandr uses a single large surface for multi-head so if the desktop size is larger than that, you will run into these sort of issues if you use a GL compositor like compiz. I thought compiz checked the max texture size reported by the GL driver would not start if the desktop exceeded that, but perhaps some versions of compiz do not enforce that.
And it may very well refuse to start from "fresh", however when you hotplug a secondary display (which is when I usually see this). The best way around the issue is to disable Compiz entirely prior to plugging in the sencondary display. After all Compiz does not add too much to the equation, and until there is a Compiz workaround by having two surfaces or if Wayland will do that when it is ready so not to exceede this apparently ubiquitous max texture size limitation (especially with lower-end/mobile GPUs [of a certain generation]), in the mean time, I guess I'm better off disabling compositing when using a dual monitor/multi display setup on this hardware.
Originally Posted by agd5f
Keith's per crtc pixmap patches should alleviate these problems if the compositer uses the new feature. The basic idea is that when a compositer is active, it can use per crtc pixmaps (i.e., one per head) as the destination for compositing rather than the root pixmap.