Whole document tree
    

Whole document tree

Miscellaneous Problems

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

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.