9. Miscellaneous Problems

9.1.1. Hardware acceleration isn't working at all

If you're getting like 1 fps, then your system isn't using hardware 3D acceleration. There's one of two things that can be going on.

1. Your 3D system is misconfigured (more likely)

2. Game X is misconfigured (less likely)

The first step is to figure out which one is happening.

1. If you have X 4.0 (X 3.* users procede to step 2), look at the output of X -probeonly. You'll see:

   (II) XXXXXX: direct rendering enabled

   or

   (II) XXXXXX: direct rendering disabled

   where XXXXXXX depends on which video card you have. If direct rendering is disabled, then your X configuration is definitely faulty. Your game is not at fault. You need to figure out why DRI is disabled. The most important tool for you to use at this point is the `DRI Users Guide'. It is an excellently written document that gives you step by step information on how to get DRI set up correctly on your machine. A copy is kept at http://www.xfree86.org/4.0/DRI.html.

   Note that if you pass this test, your system is CAPABLE of direct rendering. Your libraries can still be wrong. So procede to step 2.

2. There is a program called gears which comes with the "mesademos" package. You can get mesademos with Debian ( apt-get install mesademos) or you can hunt for the rpm on http://www.rpmfind.net. You can also download and compile the source yourself from the mesa homepage.

   Running gears will show some gears turning. The xterm from which you run gears will read "X frames in Y seconds = X/Y FPS". You can compare your system to the list of benchmarks below.

   CPU TYPE VIDEO CARD X VERSION AVERAGE FPS

   Compiling Mesa and DRI modules yourself can increase your FPS by 15 FPS; quite a performance boost! So if your number is, say, about 20 FPS slower than a comparable machine, chances are that gears is falling back on software rendering. In other words, your graphics card isn't 3D accelerating graphics.

   More important than FPS is having a constant FPS for small and large windows. If hardware acceleration is working, the FPS for gears should be nearly independent of window size. If it's not, then you're not getting hardware acceleration.

9.2.1. XFree86 4.x

If the following lines aren't present in your XF86Config file, put them in:

    Section "DRI"
        Mode 0666
    EndSection
					

This allows all non-root users to use DRI. For the paranoid, it's possible to restrict DRI to only a few non-root users. See the DRI User Guide.

9.2.2. XFree86 3.x

9.3.1. Shared interrupt

The first thing to do is to figure out if you have an IRQ conflict. ISA cards can't share interrupts. PCI cards can share interrupts, but certain types of high bandwidth cards simply don't like to share, including network and sound cards. To find out whether you have a conflict, do a "cat /proc/interrupts". Output on my system is:

    $ cat /proc/interrupts
               CPU0       CPU1
      0:   24185341          0          XT-PIC  timer
      1:     224714          0          XT-PIC  keyboard
      2:          0          0          XT-PIC  cascade
      5:    2478476          0          XT-PIC  soundblaster
      5:     325924          0          XT-PIC  eth0
     11:     131326          0          XT-PIC  aic7xxx
     12:    2457456          0          XT-PIC  PS/2 Mouse
     14:     556955          0          XT-PIC  ide0
    NMI:          0          0
    LOC:   24186046   24186026
    ERR:       1353
					

The second column is there because I have 2 CPU's in this machine; if you have one CPU (called UP, or uniprocessor), you'll have only 1 CPU column. The numbers on the left are the assigned IRQ's and the strings to the right indicate what device was assigned that IRQ. You can see I have an IRQ conflict between the soundcard (soundblaster) and the network card (eth0). They both share IRQ 5. Actually, I cooked this example up because I wanted to show you what an IRQ conflict looks like. But if I did have this conflict, neither my network nor my sound would work well (or at all!).

If my sound card is PCI, the preferred way of fixing this would be to simply move one of the cards to a different slot and hope the BIOS sorts things out. A more advanced way of fixing this would be to go into BIOS and assign IRQ's to specific slots. Modern BIOS'es can do this.

9.3.2. Misconfigured driver

Sometimes, a card is hardwired to use a certain IRQ. You'll see this on ISA cards only. Alternatively, some ISA cards can be set to use a specific IRQ using jumpers on the card itself. With these types of cards, you need to pass the correct IRQ and memory access, "I/O port", to the driver.

This is a sound card specific issue, and beyond the scope of this HOWTO. (I should write about how to pass info to the driver).

9.3.3. Something is already accessing your sound card

Perhaps an application is already accessing your soundcard. For example, maybe you have an MP3 player that's paused? If something is already accessing your card, other applications won't be able to. Even though it was written to share the card between applications, I've found that esd (the enlightenment sound daemon) sometimes doesn't work correctly. The best tool to use here is lsof, which shows which processes are accessing a file. Your sound card is represented by /dev/dsp. Right now, I'm listening to an MP3 (not a Metallica MP3, of course...) with mp3blaster.

    # lsof /dev/dsp
    COMMAND    PID USER   FD   TYPE DEVICE SIZE   NODE NAME
    mp3blaste 1108    p    6w   CHR   14,3      662302 /dev/dsp
					

fuser is similar; but it lets you send a signal to any process accessing the device file.

    # fuser -vk /dev/dsp
    
                         USER        PID ACCESS COMMAND
    /dev/dsp             root       1225 f....  mp3blaster
                         root       1282 f....  mp3blaster
					

After issuing this command, mp3blaster was killed with SIGKILL. See the man pages for lsof and fuser; they're very useful. Oh, you'll want to run them as root since you'll be asking for information from processes that may be owned by root.

9.3.4. You're using the wrong driver (or no driver)

There are only two ways to configure your card:

1. Support must be compiled directly into the kernel

2. You must have the correct driver loaded into memory

You can find out which driver your sound card is using by doing "lsmod" or looking at the output of "dmesg". Since sound is crucial for me, I always compile sound into my kernels. If you don't have a driver loaded, you need to figure out what's been compiled into your kernel. That's not so straight forward. Your best bet is to compile your kernel. BTW, let me say that compiling your own kernel is the first step towards proficiency with Linux. It's painful the first time you do it, but once you do it correctly, it becomes very easy down the right, especially if you keep all your old .config files and make use of things like "make oldconfig". See the Kernel HOWTO for details.

If you haven't compiled the kernel yourself, there is an overwhelmingly good chance that your system is set up to load sound drivers as modules. That's the way distros do things. Have everything under the sun compiled as a module and try to load them all. So if you don't see your sound card's driver with lsmod, your card probably isn't configured yet.

9.3.5. Permissions Problem

If the sound card works when you're root but not any other user, you probably have a permissions problem. If this is the case, as root, look at the group owner of the sound card using ls -l /dev/dsp; it'll probably be audio. Then, as root, add your non-root user to the audio group in /etc/group. For example, I added the users p and wellspring to group audio on my system:

    audio:x:29:p,wellspring
					

Then log out and log back in as the non-root user. Your sound card should work. Thanks to James Barton for reminding me to add this to the howto.