No, radeondrmfb is part of the open source radeon kernel DRM. The 'radeon' kernel module should have been blacklisted when you installed the proprietary driver.
Originally Posted by Sebsan
So, in my case, dri and radeon kernel modules haven't been blacklisted for an unknown reason...
Originally Posted by adamk
How can i do this manually ?
By the "modprobe -r radeon drm" command ?
Or by editing "/etc/modprobe.d/blacklist" file ?
You don't blacklist drm, just radeon. You can create any .conf filein /etc/modprobe.d. That's usally done automatically when you use my script (part of the packageing).
Okay, sorry, i ask too much noobs questions... I've found this with google on Ubuntu doc.
Originally Posted by Sebsan
I will verify the blacklist myself tonight.
Thank you all guys, i'll keep you aware.
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.
I mentioned it several times how to install it correctly. When you want to do that manually then don't blame others.
Fair enough, i will try your script.
Originally Posted by Kano
Do you mean that the official ati install script is a manually way ?
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.
So it's absolutly impossible for a non linux expert to do the job correctly, simply activate three screens with two gpu.
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.