I live in France in Rennes city, but i come from south ouest near Bordeaux
I'm so disappointed... :-(
I indeed resolved the framebuffer conflict by manually blacklisting radeon module.
But nothing really changed.
During linux boot, the kernel simply stops... just at the beginning.
Logs are not written, there's absolutly nothing in Xorg.log, in kern.log there is just ten lines and the last line was just half-writtened. I red *everything*.log in /var/log directory and there is nothing like an error nor a bug. Not even a little warning...
With radeon driver, it works pretty fine. It does the minimum but it works.
Did someone really test with success the fglrx driver with 2.6.32 kernel and Xorg 7.5 in multi gpu mode ??? (two gpu would be enough)
I'm running out of ideas.
PS: If you want Catalyst installer to blacklist radeon driver correctly, you must not remove it before or Catalyst seems to "forget" it.
The ati installer has options to build packages, those work when you stick with the default kernel (2.6.32). My script currently tunes that up to 2.6.34 using patches from arch. If you run the ati installer without those options on a heavyly modified system like U (especially lucid, but older versions had some tricky things too) or a 64 bit version when you want to use xvba the ati installer purely just does not work as expected. That's a known issue for ages. My script also uses U packages for Debian, just a bit modified in a very tricky way - when you rely on Debian packaging via the ati-installer you basically already lost. Uninstall for pure ati-installer on lucid will never work correctly due to the ld.so.conf and special overrides hacks to make the gl_conf switching work. That's why the nvidia-installer is no good idea to run there too.
If you take an unmodified system, install fglrx, then run aticonfig with the correct parameters you should be able to have three screens with two GPUs.
The more fiddling you do beforehand (I don't mean that as criticism) the greater the chance that something will go wrong.
There are sometimes problems with the distro-specific third party package-builder scripts we include with the amd.com Catalyst packages so the lowest risk approach would be to use a package provided by your distro packagers. That is what a "non linux expert" would be most likely to do.