The Linux Gamers' HOWTO
PrevNext

9. Miscellaneous Problems

9.1. Hardware Acceleration Problems

XFree86 4.0 provides a more centralized and self-contained approach to video. Much of the funkyness like kernel modules for non-root access of video boards is, thankfully, gone.

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 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 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 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. Hardware acceleration works only for the root user

9.2.1. XFree86 4.*

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.*

9.2.2.1. Voodoo cards

Voodoo card hardware acceleration only takes place ONLY at 16bpp color and fails silently when starting X in another color depth.

Also, Voodoo cards need the 3dfx.o kernel module and a /dev/3dfx device file (major 107, minor 0) for non-root hardware acceleration. Neither the module nor the device file are used under XFree86 4.*.

9.3. Why isn't my sound working?

First of all, it's probably not the game, it's probably your setup. AFAIK, there are 3 options to getting a sound card configured under Linux: the free OSS sound drivers that come with the Linux kernel, the Alsa drivers and the commercial OSS sound drivers. Personally, I prefer the free OSS drivers, but many people swear by Alsa. The commercial OSS drivers are good when you're having trouble getting your sound card to work by free methods. Don't discount them; they're very cheap (like 10 or 20 bucks), support bleeding edge sound cards and take a lot of guesswork out of the configuring process.

There are 5 things that can go wrong with your sound system:

  1. Shared interrupt

  2. Misconfigured driver

  3. Something's already accessing the sound card

  4. You're using the wrong driver

  5. A permissions problems

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 prolly 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 prolly 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.

PrevHomeNext
Hardware Emulation and Virtual Machines