If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Is "radeondrmfb" the ati proprietary framebuffer to use instead of open source "drm" ?
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.
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).
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.
Comment