Under certain circumstances, the Radeon driver corrupts colours on the screen. This is with a Radeon 9200 on an Apple Mac Mini (Freescale 7447A PowerPC G4), under Linux 2.6.12 (with the radeon framebuffer also in use on the virtual consoles, but not for X). The platform is powerpc-unknown-linux-gnu (Debian unstable) A full description (and xorg.conf) is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318812 And another screenshot demonstrating the problem is here: http://people.debian.org/~rleigh/Screenshot.png (notice the yellowed text and icons, and the yellow lines surrounding GTK+ button and line borders, and the blue cursor streaks on the area around the focussed window). It looks like this gets triggered only for certain types of drawing operation, or when a certain grab is in effect. This might be an endianness issue? So far, I've only seen GTK+ applications misbehave, but that might not be relevant. I'll be happy to do any further testing. Regards, Roger
There are swapper problems with some accel routines. do the following options help? XaaNoScanlineImageWriteRect XaaNoScanlineCPUToScreenColorExpandFill
XaaNoScanlineImageWriteRect+XaaNoScanlineCPUToScreenColorExpandFill Together: interesting yellowness on rectangle redraws under menus and all GTK+ menus are yellowed as you pass the pointer down them (when the prelight is removed), but some smaller menus are already completely ywllow. Text is still blue. XaaNoScanlineCPUToScreenColorExpandFill Only: Yellow lines + blue text. This is the same as without the option. XaaNoScanlineImageWriteRect: Same as XaaNoScanlineImageWriteRect+XaaNoScanlineCPUToScreenColorExpandFill, with excessive amounts of yellow. It looks like XaaNoScanlineImageWriteRect makes things worse, and XaaNoScanlineCPUToScreenColorExpandFill has no effect.
Created attachment 3124 [details] screenshot1.png
(In reply to comment #0) > > And another screenshot demonstrating the problem is here: > http://people.debian.org/~rleigh/Screenshot.png > (notice the yellowed text and icons, and the yellow lines surrounding GTK+ > button and line borders, and the blue cursor streaks on the area around the > focussed window). What happens: * without Option "SWcursor" * with a value for the second port for Option "MonitorLayout", such as "TMDS,NONE" * with working radeonfb in console, such that Option "UseFBDev" is actually effective, or alternatively, without that option * with depth 16 instead of 24 * without Option "DDCMode" "off" * without Option "PanelSize" * with Option "RenderAccel" "off" (In reply to comment #1) > There are swapper problems with some accel routines. Only known ones with R300 class cards.
This is fixed if I add Option "XaaNoOffscreenPixmaps" to xorg.conf. I had a dig in the source, but unlike other acceleration options, this seemed to be scattered throughout the modules in the radeon directory (xc/programs/Xserver/hw/xfree86/drivers/ati). If anyone could explain which files are relevant, I can take a look (though I know very little about X drivers). Regards, Roger
The bug is not GTK+-specific. I've also seen yellow text in an xterm after an (I assume) expose event.
(In reply to comment #5) > This is fixed if I add > > Option "XaaNoOffscreenPixmaps" > > to xorg.conf. I suspect that's a red herring. This option will probably just prevent a lot of optimizations. Have you tried any of the other experiments I asked for? Does the card work fine in Mac OS?
Here is the information as you requested: * without Option "SWcursor" - setting to "false" does remove corruption under the cursor; yellow/brown squares no longer appear. * with a value for the second port for Option "MonitorLayout", such as "TMDS,NONE" - No effect. * with working radeonfb in console, such that Option "UseFBDev" is actually effective, or alternatively, without that option - No effect. * with depth 16 instead of 24 - Fixes corruption. * without Option "DDCMode" "off" - No effect. * without Option "PanelSize" - Fixes corruption. * with Option "RenderAccel" "off" - Fixes corruption. Looking at the screenshot with the GIMP, the yellow and other colours are due to the blue channel being 0. Regards, Roger
So, would not specifying Option "PanelSize" be an acceptable solution?
That should be an acceptable workaround. Thanks, Roger
*** This bug has been marked as a duplicate of 2164 ***
*** Bug 3032 has been marked as a duplicate of this bug. ***
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.