Greetings. Argh!
I want to thank you for reading this and sharing in my frustration. Coming from proprietary linux drivers for nVidia cards, the AMD/ATI thing is a real PITA. Michael Larabel aside, I'm sure most of you won't get any joy from this.
Box is FC6, 2.6.19-1.2895, x86_64, full dev system, dual 32/64 bit packages of required libs installed (as well as many others, along with every compat- package known to man.) DFI Infinity RS482/SB400 Radeon Xpress 200, 128M shared, 256M aperature. Drivers 8.32.5 and 8.33.6
First problem, the install script doesn't detect X properly (Unknown X Window). Looking into the installer script, the called check.sh script generates this, but here's two weirdnesses with it: If I just sh check.sh, it works fine.
~]# sh check.sh
Detected configuration:
Architecture: x86_64 (64-bit)
X Server: Xorg 7.1.1
??? I don't get it. But O.K. so in reading the script I see you can force it. But when I do that, it fails again!
~]# export _ARCH="x86_64"
~]# export X_VERSION="Xorg 7.1.1"
~]# sh check.sh --nodetect
Detected configuration:
Architecture: x86_64 (64-bit)
X Server (OVERRIDEN BY USER): Unknown X Window
Even weirder, because it shouldn't show override unless --override is specified, supposedly. But further reading shows the check script calls an external lookup table, it bypasses the string manipulation part, even though it builds this exact string and passes it to the lookup table itself. Why they chose to not honor both methods... well, nevermind. This is docuemnted in README.distro, section 4dii. Using check.sh... but it's a SHELL SCRIPT, you could mention it there too, considering the paragraphs of comments put to explaining X_VERSION and all.
So after all this, it's the lookup table's fault. It doesn't have a reference to x710 / x710_64a.
Modifying the map_xname.sh script to include this, it begins to behave.
~]# export _ARCH="x86_64"
~]# export X_VERSION="x710_64a"
~]# sh check.sh --nodetect
Detected configuration:
Architecture: x86_64 (64-bit)
X Server: X.Org 7.1.x 64-bit
But still, running it from the archived installer, fails again with Unknown.
Extra command line parameters are not parsed and passed along to spawned scripts, so you cannot for instance pass --nodetect from the main ati-installer.sh, to check.sh or default_policy.sh, etc. I understand the desire to keep the scripts (semi-) simple, but this just complicates things. They all seem to parse the environment variables, so this is good.
Anyway, so setting X_VERSION and trying to run the packaged installer, gets me this now:
Error: ./default_policy.sh does not support version
default:v2::lib::x710_64a:2.6.19-1.2895.fc6; make sure that the version is being
correctly set by --iscurrentdistro
---------------
At this point, I'm just getting irritated, so decide to just build the system package, (which is how I ended up here, reading the FC packager script and finding Michael's name and web site.) Naturally I tried this method first from the packaged archive, but that was a fiasco. Having tweaked the map_xname file, I had better hopes for it now:
~]# sh ati-installer.sh 8.32.5 --buildpkg Fedora/FC6
And, you all know the troubles from here, mainly the fireglcontrolpanel issue, the two softlinks so it can find lib64/qt-3.3/lib not a non-existent lib64, and libGL, and finally it builds the RPMs without an error.
~]# rpm -ivh *rpm
Yay! I have finally, over an hour and a half later, installed the fglrx video driver. Hah, nope. I wish.
Xlib: extension "XFree86-DRI" missing on display ":0.0"
looking at the log:
(II) fglrx(0): Composite extension enabled, disabling direct rendering
(WW) fglrx(0): ***********************************************
(WW) fglrx(0): * DRI initialization failed! *
(WW) fglrx(0): * (maybe driver kernel module missing or bad) *
(WW) fglrx(0): * 2D acceleraton available (MMIO) *
(WW) fglrx(0): * no 3D acceleration available *
(WW) fglrx(0): ********************************************* *
WHAT?! Oh my. First, make your dumb driver work with Composite,
and second if your choices are DRI or no DRI, the aticonfig
sould DEFINITELY disable this by default, or at least explain
to you the difference.
Section "Extensions"
Option "Composite" "Disable"
EndSection
Anyway, now I get somewhat happier:
(II) fglrx(0): detected X.org 7.1.1.0
(II) Loading extension ATIFGLRXDRI
(II) fglrx(0): [drm] DRM interface version 1.0
(II) fglrx(0): Desc: ATI FireGL DRM kernel module
(II) fglrx(0): Kernel Module version matches driver.
(II) fglrx(0): DRI initialization successfull!
(II) Loading extension FGLRXEXTENSION
(II) Loading extension ATITVOUT
And, of course, as soon as you think you're done:
(EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib64/dri/fglrx_dri.so: undefined symbol: __driCreateNewScreen_20050727)
(EE) AIGLX: reverting to software rendering
Again, fine, if the useless extra animated graphic bits are going to cause problems, why doesn't aticonfig do it for you? It's not like it's optional at this point. (even with 8.33.6, no dice.) One assumes this will get fixed, GLX will have it's fans howling.
Section "ServerFlags"
Option "AIGLX" "off"
EndSection
Well, anyway, finally, after all this... I do have the fglrx driver running.
~]# fglrxinfo
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON XPRESS Series Generic
OpenGL version string: 2.0.6286 (8.33.6)
Three hours of my life, gone. Having to delve into scripts I didn't write, having to google for every single error along the way and find hundreds of hits, pointing out that it's widespread. Is this just because of the transition to AMD ownership? Or is this the general collapse of ATI? Either way, no nVidia install on any linux box has ever been this much trouble.
As you might guess, I'm less than thrilled. Can you imagine a non-geek trying this? They would just run the default radeon driver with software rendering. Or WORSE, an installed fglrx that isn't configured in the least, and will not do DRI and will be running Mesa for OpenGL. Bad, Bad, BAD!
-- -- -- -- -- -- -- -- --
One of the things that annoyed me the most, the ati-installer.sh script is plain retarded when it comes to positional parameters. You cannot even just run ./ati-installer.sh --listpkg because it is hard-coded to exepct the driver version as the first parameter; which of course is ignored in something like --listpkg anyway so you can just enter it twice... another example of poor scripting practices. (as are many of the error messages in all the scripts, saying error in <calling script name> when there was no calling script. Poor coding practices.
IMO this is one of the most poorly done script sets with such potential to be solid. Did they stop working midway though the process? Leaving comments in your scripts like:
# make sure we're not doing "rm -rf /"; that would be bad
is funny when your scripts are rock solid, run under any shell on any box, great sanity and error checking, etc. When inside Band-Aid scripts, it's really more PhUnNy than funny. d00d.
My point is this, ATI guys: You have every right to write your own code and keep it. But you know what? You should expect harsh critism when the average linux guy willing to fix it, is capable of fixing it. Imagine what a few really brilliant types could do with your installer. Not to mention the driver itself. But yet I just did.
Well, my system runs and my rant is done. Thanks for your time.
Have fun kids.
I want to thank you for reading this and sharing in my frustration. Coming from proprietary linux drivers for nVidia cards, the AMD/ATI thing is a real PITA. Michael Larabel aside, I'm sure most of you won't get any joy from this.
Box is FC6, 2.6.19-1.2895, x86_64, full dev system, dual 32/64 bit packages of required libs installed (as well as many others, along with every compat- package known to man.) DFI Infinity RS482/SB400 Radeon Xpress 200, 128M shared, 256M aperature. Drivers 8.32.5 and 8.33.6
First problem, the install script doesn't detect X properly (Unknown X Window). Looking into the installer script, the called check.sh script generates this, but here's two weirdnesses with it: If I just sh check.sh, it works fine.
~]# sh check.sh
Detected configuration:
Architecture: x86_64 (64-bit)
X Server: Xorg 7.1.1
??? I don't get it. But O.K. so in reading the script I see you can force it. But when I do that, it fails again!
~]# export _ARCH="x86_64"
~]# export X_VERSION="Xorg 7.1.1"
~]# sh check.sh --nodetect
Detected configuration:
Architecture: x86_64 (64-bit)
X Server (OVERRIDEN BY USER): Unknown X Window
Even weirder, because it shouldn't show override unless --override is specified, supposedly. But further reading shows the check script calls an external lookup table, it bypasses the string manipulation part, even though it builds this exact string and passes it to the lookup table itself. Why they chose to not honor both methods... well, nevermind. This is docuemnted in README.distro, section 4dii. Using check.sh... but it's a SHELL SCRIPT, you could mention it there too, considering the paragraphs of comments put to explaining X_VERSION and all.
So after all this, it's the lookup table's fault. It doesn't have a reference to x710 / x710_64a.
Modifying the map_xname.sh script to include this, it begins to behave.
~]# export _ARCH="x86_64"
~]# export X_VERSION="x710_64a"
~]# sh check.sh --nodetect
Detected configuration:
Architecture: x86_64 (64-bit)
X Server: X.Org 7.1.x 64-bit
But still, running it from the archived installer, fails again with Unknown.
Extra command line parameters are not parsed and passed along to spawned scripts, so you cannot for instance pass --nodetect from the main ati-installer.sh, to check.sh or default_policy.sh, etc. I understand the desire to keep the scripts (semi-) simple, but this just complicates things. They all seem to parse the environment variables, so this is good.
Anyway, so setting X_VERSION and trying to run the packaged installer, gets me this now:
Error: ./default_policy.sh does not support version
default:v2::lib::x710_64a:2.6.19-1.2895.fc6; make sure that the version is being
correctly set by --iscurrentdistro
---------------
At this point, I'm just getting irritated, so decide to just build the system package, (which is how I ended up here, reading the FC packager script and finding Michael's name and web site.) Naturally I tried this method first from the packaged archive, but that was a fiasco. Having tweaked the map_xname file, I had better hopes for it now:
~]# sh ati-installer.sh 8.32.5 --buildpkg Fedora/FC6
And, you all know the troubles from here, mainly the fireglcontrolpanel issue, the two softlinks so it can find lib64/qt-3.3/lib not a non-existent lib64, and libGL, and finally it builds the RPMs without an error.
~]# rpm -ivh *rpm
Yay! I have finally, over an hour and a half later, installed the fglrx video driver. Hah, nope. I wish.
Xlib: extension "XFree86-DRI" missing on display ":0.0"
looking at the log:
(II) fglrx(0): Composite extension enabled, disabling direct rendering
(WW) fglrx(0): ***********************************************
(WW) fglrx(0): * DRI initialization failed! *
(WW) fglrx(0): * (maybe driver kernel module missing or bad) *
(WW) fglrx(0): * 2D acceleraton available (MMIO) *
(WW) fglrx(0): * no 3D acceleration available *
(WW) fglrx(0): ********************************************* *
WHAT?! Oh my. First, make your dumb driver work with Composite,
and second if your choices are DRI or no DRI, the aticonfig
sould DEFINITELY disable this by default, or at least explain
to you the difference.
Section "Extensions"
Option "Composite" "Disable"
EndSection
Anyway, now I get somewhat happier:
(II) fglrx(0): detected X.org 7.1.1.0
(II) Loading extension ATIFGLRXDRI
(II) fglrx(0): [drm] DRM interface version 1.0
(II) fglrx(0): Desc: ATI FireGL DRM kernel module
(II) fglrx(0): Kernel Module version matches driver.
(II) fglrx(0): DRI initialization successfull!
(II) Loading extension FGLRXEXTENSION
(II) Loading extension ATITVOUT
And, of course, as soon as you think you're done:
(EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib64/dri/fglrx_dri.so: undefined symbol: __driCreateNewScreen_20050727)
(EE) AIGLX: reverting to software rendering
Again, fine, if the useless extra animated graphic bits are going to cause problems, why doesn't aticonfig do it for you? It's not like it's optional at this point. (even with 8.33.6, no dice.) One assumes this will get fixed, GLX will have it's fans howling.
Section "ServerFlags"
Option "AIGLX" "off"
EndSection
Well, anyway, finally, after all this... I do have the fglrx driver running.
~]# fglrxinfo
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON XPRESS Series Generic
OpenGL version string: 2.0.6286 (8.33.6)
Three hours of my life, gone. Having to delve into scripts I didn't write, having to google for every single error along the way and find hundreds of hits, pointing out that it's widespread. Is this just because of the transition to AMD ownership? Or is this the general collapse of ATI? Either way, no nVidia install on any linux box has ever been this much trouble.
As you might guess, I'm less than thrilled. Can you imagine a non-geek trying this? They would just run the default radeon driver with software rendering. Or WORSE, an installed fglrx that isn't configured in the least, and will not do DRI and will be running Mesa for OpenGL. Bad, Bad, BAD!
-- -- -- -- -- -- -- -- --
One of the things that annoyed me the most, the ati-installer.sh script is plain retarded when it comes to positional parameters. You cannot even just run ./ati-installer.sh --listpkg because it is hard-coded to exepct the driver version as the first parameter; which of course is ignored in something like --listpkg anyway so you can just enter it twice... another example of poor scripting practices. (as are many of the error messages in all the scripts, saying error in <calling script name> when there was no calling script. Poor coding practices.
IMO this is one of the most poorly done script sets with such potential to be solid. Did they stop working midway though the process? Leaving comments in your scripts like:
# make sure we're not doing "rm -rf /"; that would be bad
is funny when your scripts are rock solid, run under any shell on any box, great sanity and error checking, etc. When inside Band-Aid scripts, it's really more PhUnNy than funny. d00d.
My point is this, ATI guys: You have every right to write your own code and keep it. But you know what? You should expect harsh critism when the average linux guy willing to fix it, is capable of fixing it. Imagine what a few really brilliant types could do with your installer. Not to mention the driver itself. But yet I just did.
Well, my system runs and my rant is done. Thanks for your time.
Have fun kids.
Comment