Basic Installation Instructions for ATI All in Wonder Cards under Linux

Note that the build phase for XF86 will easily run to three or four hours. I had time to go in to Manhattan from Brooklyn, visit a couple of shops, come back on the subway again (the 'F' train, no less) and it was still compiling. Also, you will need close to 300MB of free space to hold the unpacked source files and perform the installation. By piping the process output into world.log/install.log, you free yourself up to check up on the compilation from the office, or just look through the log for problems if anything goes wrong.

Do not delete the source tree under xc since you will need it to build the ATI.2 drivers if you are building from CVS.

Backing up your clean X 4.x.x directory

After this, I'd suggest doing the following:

1. cd ..
2. tar -cvf XFree86-4.2.0-clean.tar xc
3. gzip XFree86-4.2.0-clean.tar

This will give you a clean, but already compiled, XF86 tree to use if you screw up at some point and aren't sure if your installation is still functional. After recompiling X three times (at three hours a pop) I learned the wisdom of keeping a backup around.

X Config File

You should also check your XF86Config-4 file to make sure that X will load the correct extensions when you start X. The config file can normally be found in /etc/X11/ and you'll need to add the following:

1. In Section "Module"
   • Load "glx"
   • Load "dri"
   • Load "dbe" (you may already have this)
2. In Section "DRI" (you'll probably need to create this)
   • Section "DRI"
   • Mode 0666
   • EndSection (don't forget to end the new section)

Please note that I have received reports that DRI-support is not available on all ATI cards using the default XFree drivers. There is a small, but very real, possibility that this might cause a system crash. If this occurs, then turn off DRI support and proceed to installing the GATOS driver before attempting to turn on DRI again.

At this point, if you built your kernel with the ATI Radeon module set to 'M' (instead of 'N') you should be able to test your installation using the default ATI drivers from XFree86 by running glxgears after restarting X. I seem to recall performance in the range of 900 FPS using the non-GATOS drivers. If you are getting performance in the sub-300 FPS range then DRI is not working correctly and you should check your X log for errors or issue the following command to start X: startx >& x.log and then checking x.log.

Note also that installing X from source has completely mangled my Mandrake installation -- the nice front end for rpmdrake and for configuring mount points is gone... and I haven't figured out how to get it back despite installing *drak* from rpmfind.net. You have been warned.

DRM Kernel

You're now ready to replace the XFree86 DRI modules with those from the GATOS project. This process if fairly straightforward.

1. cvs -d:pserver:anonymous@cvs.gatos.sourceforge.net:/cvsroot/gatos login
2. <hit enter to login anonymously>
3. cvs -z3 -d:pserver:anonymous@cvs.gatos.sourceforge.net:/cvsroot/gatos co drm-kernel
4. cd /path/to/drm-kernel
5. make -f Makefile.linux
6. cp radeon.o /lib/modules/2.4.17/kernel/drivers/char/drm/ (see below)

It's possible that the Makefile.linux file is missing from the CVS checkout. I poked around on the GATOS site and found a copy of this file which appeared to function correctly.

Also, if you are using the Rage128 chipset, instead of copying radeon.o over to lib/modules, you'd copy r128.o instead. Simply substitute Rage 128 wherever you see me using the Radeon module.

DRM installation alternatives

There are, in fact, three ways to complete the drm-kernel installation.

1. If you don't recompile your kernel very often then the way outline above works fine. Basically, you're just replacing the DRI driver module for the Radeon that comes with XFree86 with the one from the GATOS project. The trick is to remember that you've replaced this module, and that any time you recompile your kernel you also need to remember to copy the radeon.o file over to lib/modules again.
2. Another way to manage the new module is to insmod it at startup via a script in /etc/init.d. That way, if you recompile your kernel you don't need to remember to copy over the driver since the rc.d script will take care of it for you.
3. A third way, suggested by Lars Hugentobler, is to use 'N' for the Radeon module in the kernel config, and then place the radeon.o module in lib/modules/kernel-version/misc. Apparently, the misc directory is left untouched during module (re)compilation so you don't need to worry about either a) copying it over each time, or b) writing your own shell script to insmod the driver at startup.

I set my machine up the first way since it was the way that made sense to me thanks to a helpful list member (if you're reading this oh helpful person, please let me know your name since I've lost the original email and I'd like to add a credit), the second was recommended by the architect of the GATOS drivers, and the third is what I'd do if I were starting over again since I'm not big on shell scripting (although please note that I haven't tested this method so I make no guarantees), so you make the call.

ATI.2 drivers

Please note that it is possible to install the ATI.2 drivers as binaries so that you don't need to go through compiling XFree86. However, I found that I had far fewer issues with compiling and installing from source than I did when I tried to stay binary.

The CVS checkout here will give you the devel branch (which is required, as of this writing, for TV out). If you want to check out the main branch, just remove the "-r devel" from the checkout command.

1. cvs -d:pserver:anonymous@cvs.gatos.sourceforge.net:/cvsroot/gatos login
2. <hit enter to login anonymously>
3. cvs -z3 -d:pserver:anonymous@cvs.gatos.sourceforge.net:/cvsroot/gatos co -r devel ati.2
4. cd /path/to/ati.2
5. xmkmf /path/to/your/xfree86/tree (e.g. /temp/xc)
6. make
7. make install

This is the main reason you keep your XFree86 source code lying around. The ATI.2 drivers need to be built against the XFree86 tree, and cannot be built against /usr/X11R6.

Reboot

Now would be a good time to restart your machine to make sure that everything is running correctly at the kernel and XFree86 levels.

After starting up X, type xdpyinfo to check that DRI and XVideo are loaded and running correctly. Then run glxgears to see DRI in action. On my AGP Radeon I was getting between 600 and 900 frames per second with the ATI.2 drivers.

KM

You do not need KM installed in order to watch video input from the ATI card. KM is required only if you want to do video capture work. It is also possible to install KM after getting AVView working, so if this is your first time getting an AIW card running under Linux you might just want to skip this stage for the time being.

KM allows you to capture video via your ATI card. I have not yet tested this feature however, so although installation went smoothly I don't yet know if it actually works.

Note that if you have Video For Linux set up as a module, then you will need to first insert the v4l module using the following command:

• /sbin/modprobe videodev

Installation goes as follows:

1. cvs -d:pserver:anonymous@cvs.gatos.sourceforge.net:/cvsroot/gatos login
2. <hit enter to login anonymously>
3. cvs -z3 -d:pserver:anonymous@cvs.gatos.sourceforge.net:/cvsroot/gatos co km
4. make
5. make test
6. make install

make install installs the km module under /lib/modules/kernel-version/misc. If make test fails (because, for instance, you didn't have the v4l module -- videodev -- inserted) then you'll want to run rmmod km_api to remove the km code from the running kernel before running make test again after fixing the errors.

Beyond that, you are currently on your own since I haven't used km to actually do anything yet. I will update this section as soon as I have been able to test and use km successfully.

FFMPEG

Installing FFMPEG should be fairly straightforward. Read the instructions. Make sure that you're using a version newer than 0.4.5 (or that you patch 0.4.5).

Please note that I have received a bug report from "Joe Smack" that compiling ffmpeg with the option --enable-mp3lame will cause AVView to fail to compile. You have been warned.

1. cvs -d:pserver:anonymous@cvs.gatos.sourceforge.net:/cvsroot/ffmpeg login
2. <hit enter to login anonymously>
3. cvs -z3 -d:pserver:anonymous@cvs.gatos.sourceforge.net:/cvsroot/ffmpeg co ffmpeg
4. cd /path/to/ffmpeg
5. make
6. make install

Do not delete the ffmpeg dir after installation because AVView will need it in order to build successfully.

ALSA

Sound was the biggest headache for me. I don't know what it is about me and ALSA but we just don't get along. I highly recommend a visit to the alsa-project Web site. They seem to have added a helpful configuration tool/document (click on the 'Details' link) that wasn't available last time to walk you through the installation based on the sound card that you have. I would have discovered that you don't need to run snddevices to configure ALSA on a system with devfs support and thus saved myself a lot of grief.

I also discovered that I needed to unload any existing drivers before being able to load the ALSA drivers for my card. So after a day spent tearing my hair out it came down to:

• rmmod ymfpci
• modprobe snd-ymfpci

Avview requires the 0.9.x series of drivers and utils. You will need, at the very least, the driver and lib and util tarballs, and you want to install them in that order.

In case you've forgotten, to unzip bz2 files you just run bunzip2 name-of-file.tar.bz2, followed by the regular tar -xvf name-of-file.tar.

Remember to check if you need to run snddevices in the ALSA driver directory in order to set up the ASLA devices correctly after building and installing the drivers via make. Hint: don't do it if you have devfs support built-in (most recent Linux distros appear to have switched from making this an option to making it the default).

As far as I can tell, configuring alsa is something of a black art, and most people seem to simply appropriate someone else's working config file and adapt as necessary.

You may need to modify your modules.conf (or conf.modules, depending on the distro) file in the /etc directory. Here are the relevant portions of my modules.conf file which are for a Yamaha DX-G-somthing-or-other onboard sound card:

alias char-major-116 snd
above snd-ymfpci snd-pcm-oss
post-install snd-ymfpci alsactl restore
alias sound-slot-0 snd-ymfpci


Don't forget to set the permissions like this: chmod a+rw /dev/dsp /dev/mixer /dev/sequencer /dev/midi

Getting sound working properly was the hardest part of this process. I believe that this was in no small part because I had two sound cards -- an Aureal Vortex 2 (which is not supported by ALSA, but was supported by the kernel itself), and a Yamaha DX-G-something-or-other (which is). One was onboard, the other was in the PCI slot.

I had thought that the Yamaha (since ALSA was listing it with the YMFPCI driver) was in the PCI slot and the Aureal was onboard, but after disabling sound in the BIOS (which disabled the onboard system), I could no longer find the Yamaha but the Aureal was still showing up!

After that discovery, I decided to take the machine apart and see for myself. Sure enough, the unsupported Aureal was the one in the PCI slot, and once I had removed it and turned the Yamaha back on in the BIOS, sound setup went smoothly. Point is, before you give yourself a lot of grief because you make some assumptions about your computer's sound setup, take a look. Also, I'd suggest using only one soundcard in your system at a time (unless you're an ALSA wiz, in which case you probably don't really need this walkthrough).

The next-to-last step to getting sound working, and perhaps the most obvious but also easiest to forget is connecting the ATI card to the sound card (thanks to Brett/deek for this tip). On the All in Wonder this is done using the dongle that has a line-out jack (looks like a headphones jack). Just plug that jack into the line-in on your sound card (probably a blue input of matching size) and the other end into the S-Video out on the ATI card, and you should be set up with sound.

The final step is to turn on all of the ALSA controls. alsamixer is a good way to do this since it's relatively easy to understand. On the whole, you want to turn up everything that can be turned up (just turn your speakers way down while you're playing around) and make sure that nothing is muted. If you see a pair of M's at the top of the column, then even though you may have adjusted the sound, the channel is still muted. A good way to check that everything is set correctly is to run amixer | more. This gives you a textual representation of your ALSA channels to check against the visual one of alsamixer.

libzvbi

This was a new one since I last installed AVView. I was unable to use the standard RPMs since I'm running a fairly old Mandrake distro and the stock RPMs assume more recent versions of glibc. However, the source RPM worked just fine for me:

1. rpm --rebuild zvbi-0.2.3-1.src.rpm
2. cd /usr/src/RPM/RPMS/i686/
3. rpm -Uvh zvbi-0.2.3-1.i686.rpm

Tcl/Tk 8.4.x

Another new requirement since my last bout of avview installation (maybe it's time I updated my machine...).

1. tar -xzvf tcl8.4.2-src.tar.gz
2. cd tcl8.4.2/unix/ (assuming that you're on Unix/Linux)
3. ./configure
4. make
5. make install (no make test that I can find)

Same for tk8.4.2-src.tar.gz.

In order to get AVView to run I also had to do the folliwng:

1. Make sure that /usr/local/lib is listed in /etc/ld.so.conf and then run ldconfig
2. If all else failes then you can run export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib (since that last dir is where Tcl/TkConfig.sh is installed on my system) or add this in your .bashrc file

AVview

It took me two weeks to get Avview to compile, much less install. Whether there was an update to the CVS source, or whether something I changed enabled it to compile successfully, it nonetheless finally did after some long, frustrating evenings.

If you are installing AVview from CVS then you may have to lead off with the following commands inside the AVview directory to get things compiling on your system:

1. #autoconf
2. #autoheader
3. #automake

# generated automatically by aclocal 1.9.1 -*- Autoconf -*- 

# AM_AUTOMAKE_VERSION(VERSION)
# ----------------------------
# Automake X.Y traces this macro to ensure aclocal.m4 has been
# generated from the m4 files accompanying Automake X.Y.
AC_DEFUN([AM_AUTOMAKE_VERSION], [am__api_version="1.9"])

# AM_SET_CURRENT_AUTOMAKE_VERSION
# -------------------------------
# Call AM_AUTOMAKE_VERSION so it can be traced.
# This function is AC_REQUIREd by AC_INIT_AUTOMAKE.
AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
     [AM_AUTOMAKE_VERSION([1.9.1])])