For the Google index:
If you’re one of the (no doubt many) people out there suffering from intermittent ATI Radeon bitmap corruption when running Compiz or another desktop accelerator under Xorg, here’s how to fix the problem entirely. This is the correct fix for you if turning off AccelDFS fixes corruption but makes your desktop unbearably slow.
Why the ATI driver maintainers don’t implement this I’ll NEVER KNOW, but luckily you can take care of it yourself:
(1) Visit rpmfind.net and get ahold of the latest xorg-x11-drv-ati for your distribution. For Fedora 12 right now, it’s 6.13.0 (with some date characters afterward). You want the SOURCE file (.src.rpm), not the binary (.i386.rpm). If you’re not using an RPM distro, get ahold of the source tarball for your radeon_drv.so driver.
(2) Install the sources and/or extract the tarball. On Fedora, this means:
rpm -i xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12.src.rpm
tar -xJvf xf86-video-ati-20091221.tar.xz
(3) Go to the src/ subdirectory in that hierarchy:
(4) Open the file radeon_exa_funcs.c and find ONE of the following TWO lines in the file (only one of them will appear, depending on your version of the driver):
if (bpp != 24 && RADEONGetDatatypeBpp(bpp, &datatype) &&
if (info->accelDFS && bpp != 24 && RADEONGetDatatypeBpp(bpp, &datatype) &&
(5) Change the line present in your file to match the appropriate line below (basically adding “w>32 &&” in either case):
if (bpp != 24 && w>32 && RADEONGetDatatypeBpp(bpp, &datatype) &&
if (info->accelDFS && bpp != 24 && w>32 && RADEONGetDatatypeBpp(bpp, &datatype) &&
(6) Save the edited radeon_exa_funcs.c and at the command line. Next you’re going to compile the driver. If you get errors performing the steps, you’re missing files for which you need to install relevant -devel (source header) packages. In such cases, use a site like rpmfind.net or rpm.pbone.net to help you determine which -devel packages you’re missing by searching for the needed filenames and installing those packages. Once all is said and done, a successful compilation will proceed using these commands:
(7) Copy the radeon_drv.so file to the appropriate modules directory where the file “radeon_drv.so” already lives (you can find this with “locate radeon_drv.so”). NOTE THAT THIS WILL CRASH YOUR DESKTOP and force you to re-login. So be prepared.
cp radeon_drv.so /usr/lib/xorg/modules/drivers
ONCE YOU HAVE DONE all of this, your screen corruption should be gone.
The problem is that the driver is operating so fast that when it copies bitmaps from the display area sometimes, the bitmap copy orders are encountered before that bitmap actually arrives on the screen. This check just makes sure that for sufficiently small pixmaps (where this timing is most likely to occur), copy-from-screen isn’t used (because it corrupts things at this level), while it is still used for larger pixmaps (because it slows the display wayyyy down otherwise).
Why the maintainers can’t get this fix into place is beyond me. I keep hand-applying it throughout several Fedora revisions every time new versions of the Xorg packages come down the pipe.
BECAUSE WHO LIKES RANDOM SCREEN CORRUPTION?!
Not me. Sometimes the Linux community needs to get with the program and just implement “kludgy but works” fixes for the sake of the user, rather than waiting ten years for the “correct and works” version to finally slide out of someone’s brain.
P.S. If you install this fix and it works for a while and you later find that screen corruption suddenly returns, that indicates that your system has installed an update that replaced your “hacked” version of the driver with an updated “official” version of radeon_drv.so. Meaning that to get rid of the corruption once again, you’ll need to repeat this process.
Sorry, non-technical people, for the most boring blog post ever. But I really wanted to put this out there into netspace so that others having the problem can fix it.