to pollute my damned Facebook wall as much as possible.

So clearly I’m not the only person who’s experienced the desire (need?) to link together a bunch of disparate strands of life. After all, some of us have been hosting our own little narcissistic corners of the web since the ’90s or before and are loathe to let them (or our own maintenance of the data in them—our lives, after all) entirely go.

At the same time, Facebook and Twitter and the socialmajigamaweb are new and shiny and sexy and really rox the rox, so it’s necessary to use them, naturally. But then you’ve got two or four or six or eight different sites and you’re supposed to post to them all, stay active everywhere?

Not likely.

So here’s what I’ve got so far:

Web -> Drupal (PC posting route)

BlogPress -> Drupal (iPhone posting route)

Drupal -> Twitter (when posting via web using PC)

BlogPress -> Twitter (duplicating Drupal posts, when posting via iPhone)

Facebook <- Drupal RSS (pulling via wall monitoring into notes, i.e. here) I guess it's hella normal to have Facebook pull a bunch of other stuff, too (in my case, Delicious, Yelp, Picasa). Are there other exciting pulls and/or integrations I ought to be making here? Or is that social enough? Am I fscking social enough or what? Already...?

So with Ania getting into Facebook in a big way all of a sudden, I’ve become motivated again to try to figure out how to integrate a self-hosted Drupal account with Twitter, Momo, Facebook, Picasa, and whatever else I happen to be using these days in my online life.

So far it isn’t easy. I would seriously kill just for an iPhone app that could use Drupal to it’s fullest, not to mention the rest.

– Posted using BlogPress from my iPhone

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

cd /root/rpmbuild/SOURCES

tar -xJvf xf86-video-ati-20091221.tar.xz

(3) Go to the src/ subdirectory in that hierarchy:

cd xf86-video-ati-20091221/src

(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:

cd ..

./autogen.sh

./configure

make

(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.

cd src/.libs

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.