trying to use the ati drivers with 2.6.0-test1

i've been trying for a while to make ati's drivers work with 2.6.0-test1. supposedly the next version of the drivers will support 2.6, but of course, i couldn't wait. i've made some progress, but i'm a little stuck now. i'm still trying, but i figure i would post what i've gotten so far in case someone else wanted to try.

first of all, i am trying the new experimental drivers - version 3.2.03. they were posted for a little while on the ati driver page at http://www.schneider-digital.de/html/download_ati.html, but were pulled and it's back to 2.9.13_2. but some people got them, so if you look around the net, you can find them. i want to use them because they support FSAA and tv-out, which is nice. i haven't tried making 2.9.13_2 work yet. maybe i'll give them a shot when i get frustrated and give up on 3.2.

ok, the following requires a little source code editing:

in 2.6, the module format has changed, and some old stuff is deprecated. so we need to replace a couple old functions in the source with their newer counterparts.

the files that we need to edit are agpgart_be.c and firegl_public.c in the /lib/modules/fglrx/build_mod directory. (or the equivalent, if you put it somewhere else) go through these files, and replace all occurences of

"MOD_DEC_USE_COUNT"

with

"module_put(THIS_MODULE)"

(without quotes, of course)

likewise, replace all occurences of

"MOD_INC_USE_COUNT"

with

"try_module_get(THIS_MODULE)"

MOD_DEC_USE_COUNT and MOD_INC_USE_COUNT are deprecated - you'll see messages about that if you try and compile without replacing those functions. note - these are case sensitive; i remember at least on occurrence of 'mod_dec_use_count()', but that's a function. i'm pretty sure that shouldn't be changed, but i may try changing it sometime if i can't make it work.

one other change - in firegl_public.c, change any occurrences of

"pmd_offset"

to

"pmd_offset_map"

another note - if you're using a text editor to search and replace, make sure you're replacing _just_ pmd_offset. there's at least one occurrence of pmd_offset_map in there already, so a search and replace all will change that to pmd_offset_map_map, which doesn't exist.

that's all the source code editing we need to do. however, the old make.sh script won't work anymore. the module format has changed to the extension *.ko, so we need to create our own Makefile. so create a file called 'Makefile' in that build_mod directory, and put this bit of script in there:

ifneq ($(KERNELRELEASE),)

EXTRA_CFLAGS := -DFIREGL_410 -DFGL_LINUX253P1_VMA_API -Idrivers/char/drm/ -DFGL
obj-m := fglrx.o
fglrx-objs := agp3.o nvidia-agp.o agpgart_be.o i7505-agp.o firegl_public.o libfglrx_ip.a.GCC3

else
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
endif


one thing that is not showing up is whitespace, since the forum seems to remove it from posts. there is an important bit of whitespace in front of the $(MAKE) line, under 'default:'. all commands have to have a tab in front of them, or else make won't see that it's a command and will skip it. so, those last three lines should actually be like:

default:
<tab>$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
endif

with '<tab>' being an actual tab.

now run 'make' in that build_mod directory. it should compile, and you'll end up with a file called 'fglrx.ko'. you can install that into your modules directory or just insmod in directly. i insmod it because it would become a pain to move the file around every time i used a new kernel.

so after removing the radeon.ko module and insmod-ing the fglrx.ko module, i ran startx and ended up with a black screen... i ssh'd into the comp and looked at the X log. the log ends with these lines:

drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmGetBusid returned ''
(II) fglrx(0): [drm] created "fglrx" driver at busid "PCI:1:0:0"
(II) fglrx(0): [drm] added 8192 byte SAREA at 0xf9f34000
(II) fglrx(0): [drm] mapped SAREA 0xf9f34000 to 0x40228000
(II) fglrx(0): [drm] framebuffer handle = 0x90000000
(II) fglrx(0): [drm] added 1 reserved context for kernel
(II) fglrx(0): DRIScreenInit done
(II) fglrx(0): Kernel Module Version Information:
(II) fglrx(0): Name: fglrx
(II) fglrx(0): Version: 3.2.0
(II) fglrx(0): Date: Jul 10 2003
(II) fglrx(0): Desc: ATI Fire GL DRM kernel module
(II) fglrx(0): Kernel Module version matches driver.
(II) fglrx(0): Kernel Module Build Time Information:
(II) fglrx(0): Build-Kernel UTS_RELEASE: 2.6.0-test1-mm2
(II) fglrx(0): Build-Kernel MODVERSIONS: no
(II) fglrx(0): Build-Kernel __SMP__: no
(II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000
(II) fglrx(0): [drm] register handle = 0xe0000000

and that's it, even with 'startx -- -logverbose 8'.

i saw that there was no smp support, and was confused, since i _am_ running smp. since the make.sh script probably detected and set it before, and i couldn't use the script now, i had to set it some other way. i forced it by manually defining it near the top of firegl_public.c with the line

#define __SMP__

... but i have a feeling that that's bad and probably not the way i should do it. whatever; this whole thing is already a hack job as it is. fortunately, doing that changes the line in the x log to

(II) fglrx(0): Build-Kernel __SMP__: yes

which is better, i suppose. but the log still stops at the same spot, and x still gives me a black screen.

so that's where i am now. it compiled and inserted into the kernel without problems, which is good progress. i'll continue messing around with it. but anyone who wants to can try this and see if they can get better results or figure out what's wrong.

good news for gentoo users running 2.6-test1 - the newest version of the ati-drivers in portage (2.9.13-r1 - it's not even listed, you have to manually emerge /usr/portage/media-video/ati-drivers/ati-drivers-2.9.13-r1.ebuild) are hacked up to work with 2.6, so i don't have to bother with this anymore. i took a look and they ended up doing similar stuff that i did. but spyderous and lu_zero (the devs who hacked this up) did it a cleaner way than replacing deprecated stuff with newer replacements. for example, instead of replacing pmd_offset, they put this piece of code at the top:

#include <asm/pgtable.h> //for pmd_offset

#ifndef pmd_offset

static inline pmd_t * pmd_offset(pgd_t * dir, unsigned long address)
{
return (pmd_t *) dir;
}

#endif

so they didn't have to do any replacing of that function. (naturally, they'd be better at this than me)

so now i'm running 2.6.0-test1-mm2 with ati-drivers 2.9.13, and i get really great fps in quake3 - i ran a demo that came with challenge promode arena that was a bunch of running around with not much action, and got 226 fps. and the traditional 'four' demo that comes with quake gave me something in the high hundreds. (don't remember exactly.)

there's only one tiny bug... the fglrx module just shows up as "1" in the lsmod list. but whatever; i have a nice fast dev kernel, and an accelerated 2d desktop as well as accelerated 3d with the ati-drivers, so i'm satisfied. now the next step is to wait for them to re-release 3.2, which will compile natively with 2.6 and will support FSAA and tv-out.

no prob; a stupid question to one person could be a perfectly logical question to someone else.

xfree is, for the most part, set up the same way. however, there are a couple nuances:

there is actually a synaptics driver built into the kernel. it doesn't replace the need for a mouse driver, but it sets up the synaptic driver from the start, in case you don't use x at all and use gpm or something.
however, the way it exports the mouse device is no longer the same - it's not /dev/psaux anymore. it's run through the event interface, which you need to enable support for under "Input Core", and then the device will be /dev/input/eventx. (it depends, you can cat and test to see which it is. for example, mine is /dev/input/event0)
you also need an event interface-aware synaptics driver.

http://w1.894.telia.com/~u89404340/touchpad/

this driver is an updated version of the one at tuxmobil, with support for the event interface. (plus other fixes, like getting that center scroll button working, etc) just use that driver as the mouse driver for X, the device is the event interface device, and the protocol is "event".


as to the 3d drivers:
drm or ati is still a matter of preference, as it always has been. ati drivers have 2d acceleration and better 3d performance in games, but tend to use the cpu a lot and generate heat. drm is open source, more stable, and easier on the cpu (both during games and while idling in x), but not as fast.

i personally use the ati-drivers; i _would_ use drm since i'm usually on the desktop, but i use all sorts of graphical features in fluxbox like transparent menus, rounded corners, transparent terminal windows, etc, so 2d acceleration helps that out. i just throttle it.

you can switch between these if you want to (though i don't really see why). it requires just an unload of the old module, load of the one you want to use, changing your XF86Config (actually, i have two... XF86Config.drm and XF86Config.ati, and i just symlink into place the one i want to use), and running an opengl-update xfree or opengl-update ati, whichever is appropriate.

notes on using these drivers:

for both of these, you must have agpgart compiled directly into the kernel, along with the correct chipset, or else direct rendering won't work.

the ati-drivers require hacking up, but since you're using gentoo, just emerge the ebuild i mentioned above. however, you _must_ tell the drivers to use an external agpgart (the option in the xf86config is something like "useinternalAGPGART" "no", check what fglrxconfig outputs). the drivers will hang if you try and use their internal agpgart.

with drm, just enable support in the kernel for drm, and set 'ATI Radeon' as a _module_. (the dev kernel drm is updated so you no longer have to use an external package. in fact, _don't_ install the xfree-drm ebuild) this is important; x tries to load the radeon module if it's not loaded - the problem being, it will try and load the old 2.4 driver, which will make things hang. if support is directly in the kernel or not present at all for radeon, x will see no radeon module loaded, and will load the old module and crash. if it's a module and autoloaded at boot (or loaded sometime before starting x), x will see the radeon module is loaded, and use that one without loading the old one.

what else is a heads up with 2.6...

make sure you emerge module-init-tools, these are the new module loading tools for 2.6; the old ones don't work anymore.

make a directory, /sys. 2.6 uses sysfs mounted there, which is like proc, but a lot better and cleaner. proc will still be mounted, but you have to make that directory for sysfs to mount. 2.6 modules use sysfs to export status info now.

in kernel config, you _need_ Unix98 PTY support (in character devices, i think? don't remember) as opposed to 2.4, where you didn't. and, subsequently, enable devpts support under 'pseudo filesystems' in file system support. you also need to enable a couple VT options that you didn't have to in 2.4. (i don't remember which ones; just build a 2.6 config from scratch instead of copying over a 2.4 one, and you should be fine without worrying about VT)

in /etc/modules.autoload.d, create kernel-2.6. (to match the other kernel-2.4 and kernel-2.5 in there.) use that to specify modules to autoload.

with the alsa driver - if you use the one in the kernel (which you should), then unmerge the alsa-driver ebuild. however, other programs that have the alsa use flag enabled will complain about it not being there, so inject it into portage, since you technically have it as part of the kernel, just not as a separate package. the /etc/init.d/alsasound script won't be there anymore... you can find or make a script to replace it for storing and reloading mixer settings, but i just use 'alsactl restore' and 'alsactl store' in local.start and local.stop, respectively. less work.

oh yes, the device system during boot has changed for me. (most people don't have this problem, but it's present in the mm patches. it'll be fixed at some point, but this is just in case you run into it) specifying 'root=/dev/hdax' in grub as a kernel parameter won't work anymore for me. (i get a 'VFS unable to mount root' error for reiserfs partitions) so here is how you specify it:

root=0306 (which is equivalent to /dev/hda6)

this is the major and minor device number of the hard drive, and the partition.

03 is the major device number of the first ide bus, encompassing hda and hdb. (the leading zero is ignored, so you could just do 306, but i put the 0 there for organizational purposes)

the 0 after that is the minor device number. hda has a minor device number of 0, and hdb has a minor device number of 64. however, that 64 is in hexadecimal, so it's actually 4. (4x16=64)

and 6 is the partition number.

so, hda1 is 0301, hda4 is 0304, hdb1 is 0341, hdb3 is 0343, etc. you get the idea. i'm not going to bother going into hdc and on, since i doubt you'd be booting from a drive that's not on the first ide bus.

um... if you're into that sort of thing, you can change the elevator the scheduler uses by appending the elevator= parameter to grub. so, elevator=as for the anticipatory scheduling elevator, and elevator=cfq for the controlled fair queueing elevator. anticipatory scheduling is the default, and is the better one anyway, so you probably don't have to worry about this. but just in case...

... that's all i can think of at the moment. i'll post again if i remember anything i missed.

sorry, i can't really help you with svgalib; i don't use it directly and have never had compilation problems with it. i prefer the framebuffer. what you might want to do is either merge a newer masked version, in case there's a bug fix, or you could search gentoo bugzilla and see if someone has a patch or updated ebuild or solution (or something).

actually, i haven't found a place that explicitly lists the mm-sources changes; if i'm really curious, i just read the patch file. i know it almost always includes con kolivas's Oxint scheduler patches. however, since it always includes the latest patches, there is more of a possibility that something could break, so don't use them if you don't want to risk that. my 2.6.0-test1-mm2's usb driver is broken on occasion, so i can only use my usb mouse about half the time. and the wpadding patch that was in -mm1 broke compilation with gcc3 for a few people. and sometimes, the Oxint patches make a bad combo and cause the comp to slow down to a crawl. (mm-sources is essentially the testing branch for the test kernel)

changing to the mm-sources from the dev kernel is just like switching from vanilla to gentoo; you just redo and switch the kernel (like you said, emerge, build, symlink). you don't have to recompile anything else, unless you're using the device mapper for LVM; at that point, you would have to recompile libdevmapper.

i believe the newer versions of the ati drivers, 3.2.0 and up, compile for 2.6 natively. try them if you haven't already:

http://www.schneider-digital.de/html/download_ati.html

if you still can't get it to work, i can port the ebuild to a shell script if you want.

if you want to take a risk, you could try the 2.6 test drivers. they come with software suspend, and also have experimental acpi sleep state support. (i haven't tried either feature, though)

have you tried using the 2.4.21 patch on 2.4.20? it's only a minor revision change; it may work anyway. and if it doesn't, there will probably be just a few hunks you have to edit by hand.

the 3.x series is slower in general, for some reason. but it supports cool stuff like FSAA.

the ati-drivers have a lot of game-specific optimizations. try fgl_glxgears, or a quake3 timedemo to compare. they also have 2d acceleration.