Talk:Problems with fglrx
Contents
using kernel AGP vs fglrx AGP
Anyone know whether this makes a performance and/or stability difference?
8.20.8 and later works with current Debian sid packages
spiney@t43p:~$ dpkg -l xserver-xorg Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-============================-============================-================== ii xserver-xorg 6.9.0.dfsg.1-2 the X.Org X server spiney@t43p:~$ fglrxinfo display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: MOBILITY FireGL V3200 Pentium 4 (SSE2) (FireGL) (GNU_ICD) OpenGL version string: 1.3.5519 (X4.3.0-8.20.8)
--spiney
Ahh - thanks for the info. You perhaps compiled the modules for the drivers yourself and did not use the debian packaged fglrx-driver? Thus, it must be an unneeded limitation on the debian packaged driver which limits its installation... Full listing at http://packages.debian.org/unstable/x11/fglrx-driver which lists as required packages:
xserver-xorg (<< 6.8.99) the X.Org X server xserver-xorg (>= 6.8.0)
The first limitation (<<6.8.99) is what prevents installation. I'm sure I could force apt to install it, but I may go back to compiling the modules myself, as using fglrx 8.20.8 with kernel 2.6.15 needs a small patch to compile correctly anyway... --gsmenden
Spiney, where exactly do you have your package from? I re-build the 8.20.8-package from debian with the <<6.8.99 dependecy removed, but when I try to run X, I get
[R200Setup] X version mismatch - detected X.org 7.0.0.0, required X.org 6.8.0.0 (EE) Failed to load module "fglrx" (module requirement mismatch, 0)
Any hints? --[User:nomeata|nomeata]
I used the ati-installer (the huge download), created a Debian sid package and installed it, but got the same error. The installer seems to fetch the wrong driver version from the archive, so I extracted it with
./ati-driver-installer-8.20.8-i386.run --extract <sometempdir>
and put the necessary files from the created <sometempdir>/x690 subdirectory into /usr by hand. All IIRC, it's been some time since. :)
--spiney 07:29, 11 Jan 2006 (CET)
Thanks for the pointer. This is how you get proper debian packages out of the ati-installer:
./ati-driver-installer-8.20.8-i386.run --extract fglrx-tmp cd fglrx-tmp $editor packages/Debian/ati-packager.sh # in the line "sid|unstable) X_DIR=x680;;", put a x690 for the x680 ./fglrx-tmp/packages/Debian/ati-packager.sh --buildpkg sid cd .. sudo dpkg -i fglrx-kernel-src_8.20.8-1_i386.deb fglrx-driver_8.20.8-1_i386.deb
--Nomeata 00:35, 13 Jan 2006 (CET)
I had to do following steps :
$ ./ati-driver-installer-8.20.8-i386.run --extract fglrx-tmp $ cd fglrx-tmp $ editor packages/Debian/ati-packager.sh # in the line "sid|unstable) X_DIR=x680;;", put a x690 for the x680 $ ./packages/Debian/ati-packager.sh --buildpkg sid $ cd /tmp $ sudo dpkg -i fglrx-kernel-src_8.20.8-1_i386.deb fglrx-driver_8.20.8-1_i386.deb
--Fbianco 13:36, 26 February 2006 (CET)
Nice - confirmed works on my T43p running sid. From then on (or until 8.21.x comes out) you'll have to tell apt to hold back fglrx-driver package, or it will try to "update" fglrx-driver to 8.20.8-1.1 and therefore revert back to the problematic drivers. --gsmenden
Thanks for the info, Nomeata, that's a lot cleaner a solution than my manual way.
--spiney 08:32, 13 Jan 2006 (CET)
To get this working under 2.6.15 with x.org 6.9, you will also need to apply a small patch - there is a link on the main article page. After you install the fglrx-driver package with the 6.9 versioning hack above, go to /usr/src/modules and copy the patch here. Modify the first two lines of the patch file to take out the "build_mod" directory, e.g. first line should begin with
--- fglrx.orig/firegl_public.c
and call it with the -p0 strip option. It should patch the firegl_public.c file cleanly. You can then install as usual for your kernel (2.6.14.x or 2.6.15) using module-assistant.
Update - although X will come up in kernel 2.6.15 with the fglrx drivers patched as above, there is some strange behavior exhibited in all of X apllications - frequent hanging of applications when closing windows. Reverting back to the radeon driver in 2.6.15 solves these - so it is likely the ATI proprietary driver causing some problems.
Yet another update - fglrx 8.21.7 is out as of 1/19/2006, now supporting OpenGL 2.0, so eventually we will have beautiful complex shading / fog effects on Linux, too. It works well with X.Org 6.9 out of the box.
Unfortunately, this version gives the same problems when used (unpatched) with kernel 2.6.15 with strange lockups occasionally requiring reset of X. I have not tried this with the ~10 line patch listed on the main site, but that patch not work for me with 8.20.8. Anybody else have experience with 2.6.15 and fglrx?
Yay - new version out - 8.22.5 - works well with 2.6.15.x. Finally, running a plain-vanilla kernel on a T43p! (SATA+libata passthrough+SMART in mainline, 3d accel drivers up to date. Linux life is good.)
--gsmenden 12:39, 9 Feb 2006 (EST)
I don't know which patch you mean exactly (10 lines? the patch from lkml is just one line changed, no?), but I've been using 8.20.8 with 2.6.15 for quite some time (actually started with some -rc version IIRC), no lockups at all. No idea about 8.21.7 though, because I switched to 2.6.16-rc1 and can't compile the fglrx module at the moment, need to investigate the cause.
--spiney 07:24, 21 January 2006 (CET)
Ok - strange. Yeah, the actual change is only one line, the rest is just commenting, etc. The lockups that I get are quite rare, but flightgear occasionally gives a hard lock. glxgears and fgl_glxgears work fine, netscape occasionally will hard-lock, and strangely enough issuing a shutdown command often makes the display blank and hard lock. I can't reproduce them too consistently, but these _never_ occur with the radeon driver / mesa or under 2.6.14.x.
Unfortunately vanilla 8.21.7 with kernel 2.6.15.1 (Xorg 6.9) gives the same X lockups.
--gsmenden 11:36, 21 Jan 2006 (EST)
I can't compile the 8.21.7 driver modules with 2.6.15.1 at all. They compile with 2.6.14.4 cleanly and 8.20.8 compile with 2.6.15.1. What I don't understand though is, that when I let the ATI installer build debian packages, it does so without hassle, but the packages don't work. (this is about 8.21.7 - 2.6.15.1) Also patching doesn't seem to help. It shouldn't of course.
--Rasto 15:04, 23 Jan 2006 (CET)
I looked at the compile problems last night. I have no idea, how it is possible that it works for other people with 2.6.15, perhaps when you install precompiled modules? I don't really understand how that ati-installer thing works. Anyway. This may solve the problems with 8.21.7 and 2.6.15- it is just two minor line changes (+ the one line patch with little extra), but now it compiles. pm_register and similar were moved to linux/pm_legacy.h in 2.6.15, so that's one problem. It also reports unknown symbol verify_area, but this should not pose a problem, as it is already obsolete and redundant. If you feel, that the one line should be left as the separate patch, copy it somewhere else and change it. It's here [1], but I'll put it on the main page as well.
--Rasto 18:29, 25 Jan 2006 (CET)
Disabling the external VGA port?
Does anyone know how disable the VGA port completely even when a cable is attached? Fiddling around with the DesktopSetup and ForceMonitor options didn't do the trick for me, and the MonitorLayout option found in some documentation is no longer valid in the current fglrx driver.
--spiney 19:42, 10 Jan 2006 (CET)
Debian-specific script to switch fglrx<->radeon
Don't know where to put it exactly, but if someone's interested (and using Debian), I've put up a script for easily switching graphics driver configurations. Feedback appreciated (altho I haven't got any to the xscreensaver patch ;)), especially if someone could do something similar for other distributions (Gentoo being half-way there it seems) and incorporate it into the script.
--spiney 15:25, 17 January 2006 (CET)
Compile ATI driver???
How can you compile a binary only distributed driver? If I'm not getting something wrong, please change the formulation of the just added info. Wyrfel 20:10, 25 January 2006 (CET)
[2] "The driver as a whole is made of three main components: the driver proper, a replacement libGL and a kernel module. The driver and libGL are in the fglrx-driver package, the kernel module's source code is in the fglrx-kernel-src package." --Dunno 23:49, 13 February 2006 (CET)
Yepp, my fault, didn't think of the kernel part when i wrote that. Wyrfel 02:50, 14 February 2006 (CET)
On Kernel 2.6.16(_rc4-mm1) fglrx doesn´t load anymore
Hi,
if i emerge ati-drivers 8.22.5 and try to modprobe it on Kernel 2.6.16_rc4-mm1 i get the following console output:
FATAL: Error inserting fglrx (/lib/modules/2.6.16-rc4-mm1/video/fglrx.ko): Unknown symbol in module, or unknown parameter (see dmesg)
my dmesg Output reads:
fglrx: Unknown symbol inter_module_unregister fglrx: Unknown symbol inter_module_get_request fglrx: Unknown symbol inter_module_put fglrx: Unknown symbol inter_module_register
from the ati-driver wiki i know that the driver runs on 2.6.16 up to rc3. But on the mm Series it doesnt run since 2.6.15.4-mm4.
Help would be appreciated...
Thanks and Greets
Oli
Have a look at the (currently) last entry on http://www.rage3d.com/board/showthread.php?t=33847019, which explains how to revive the old inter_module routines. HTH
--Nephilim 19:41, 22 March 2006 (CET)
Link to the specific post: http://www.rage3d.com/board/showthread.php?p=1334242855#post1334242855 --Thinker 20:00, 22 March 2006 (CET)
I have a t43p / Debian Sid running 2.6.16 debian kernel compile the debian way. And the fglrx modules compiled. There are two problems that I can not seem to fix...
o If I log out of kde to kdm/ or the login, everything goes black, even Alt+Ctrl+F1 does not work.
It is not locked up as Ctrl+Alt+Del does a proper restart. o The other problem is on the second monitor the screen boundary is not right.
Putting the mouse to the bottom cause a vertical blur.
As long as the mouse is not at the bottom of the second screen all is well.
--Lters 14:35, 7 April 2006 (CEST)
