Whole document tree
    

Whole document tree

Linux Quake HOWTO: Tips & Tricks Next Previous Contents

6. Tips & Tricks

6.1 Running X and GL games without setuid

If you only run the X and GL versions of Quake, QuakeWorld or Quake II, you don't need to run them with root permissions. SVGA is the only mode that must be run as root. The X versions just need access to /dev/dsp, the sound device. The GL versions need access to the 3Dfx card as well as to /dev/dsp.

/dev/dsp needs to be readable and writeable by Quake. Most distributions give it 662 (rw-rw--w-) permissions by default. The simplest solution is to just chmod 666 /dev/dsp. On most systems, the ability to read from the sound device will not pose a significant security threat. If this approach is unacceptable for your system, create a group that owns /dev/dsp and make your Quake players members of that group.

You need the /dev/3dfx driver from Daryll Strauss' glide page ( http://glide.xxedgexx.com/3DfxRPMS.html) in order run glide applications (like GLQuake) non-root. Download the Device3Dfx.xxx.rpm package and install according to the instructions on the web page. After you've installed the driver, make sure /dev/3dfx has 666 permissions (chmod 666 /dev/3dfx).

When /dev/dsp and /dev/3dfx are properly set up, you can remove the setuid bit from your Quake/QW/Q2 executables. Just do (as root) chmod 0755 XXXXX, where XXXXX is either glquake, quake.x11, or quake2.

If you've been playing as root prior to making these changes, many of your Quake files (like savegames) may be owned by root and inaccessible to a normal user, so remember to change the files' ownership before you attempt to play the game non-root.

6.2 Running SVGA and GL games from X

The GLX Quakeworld and Quake II clients are native X applications, but since they use Mesa rather than the 3Dfx mini-driver, they're slower than the lib3dfxgl.so versions. For this reason, you may still favor this way of starting games from X over using the GLX clients.

This is based on a Linux Gazette 2 Cent Tip by Joey Hess ( joey@kite.ml.org) The original is at http://www.ssc.com/lg/issue20/lg_tips20.html#squake

Yes, it's possible to run the Quake games from X if you're root, but such behavior is naughty, and you still run the risk of having Quake crash and leave the console unresponsive. With a little work you can make it possible for a regular user to run SVGA and GL Quake from X AND automatically switch back to X when the program is finished, regardless of whether it exited normally or not.

Note: when I say "Quake" in the text below, I really mean "quake, glquake squake, qwcl, glqwcl, qwcl.x11 or quake2".

  • First, you'll need the open(1) package by Jon Tombs. This is a set of two very small programs that allow you to switch between virtual consoles and start programs on them. Download open from http://sunsite.unc.edu/pub/Linux/utils/console/. You shouldn't have to do much more than make;make install to compile and install it. Once it's installed, you need to make the open and switchto executables setuid root. So do this:
         cd /usr/local/bin
         chown root open switchto
         chmod 4755 open switchto
         
    
  • Next, save the following code to a file called getvc.c:
            /* getvc.c
             * Prints the number of the current VC to stdout. Most of this code
             * was ripped from the open program, and this code is GPL'd
             *
             * Joey Hess, Fri Apr  4 14:58:50 EST 1997
             */
                 
             #include <sys/vt.h>
             #include <fcntl.h>
               
             main () {
               int fd = 0;
               struct vt_stat vt;
                 
               if ((fd = open("/dev/console",O_WRONLY,0)) < 0) {
                 perror("Failed to open /dev/console\n");
                 return(2);
               }
               if (ioctl(fd, VT_GETSTATE, &vt) < 0) {
                 perror("can't get VTstate\n");
                 close(fd);
                 return(4);
               }
               printf("%d\n",vt.v_active);
             }
                
             /* End of getvc.c */
         
    

    Compile it and install it somewhere in your $PATH:
         gcc getvc.c -o getvc
         strip getvc
         mv getvc /usr/local/bin
         
    
  • Now create a script called runvc: your $PATH:
         #!/bin/sh
         # Run something on a VC, from X, and switch back to X when done.
         # GPL Joey Hess, Thu, 10 Jul 1997 23:27:08 -0400
         exec open -s -- sh -c "$* ; chvt `getvc`"
         
    

    Make it executable and put it somewhere in your $PATH:
         chmod 755 runvc
         mv runvc /usr/local/bin
         
    
    Now you can use the runvc command to start Quake. Continue to use whatever command line you usually use to start your game, but put runvc at the beginning:
         runvc ./quake2 +set vid_ref gl +connect quake.foo.com
         
    
    You'll automatically switch to a VC, run Quake and then switch back to X when it's done!

  • Update: Joey Hess wrote in to say:
    I'd like to point out that some people may find that this doesn't work. If your /dev/ttyxx devices do not let you write to them by default (a good idea), then the open command won't be able to switch to them. In that case, you need to chown the next tty that is free after you start up X. I do this in xdm's Xtartup_0 script, as follows:
         # Set up tty8 as a console that is writable by the current user, so 
         # open -s commands can be used to run stuff there.
         # Tty8 is used becuase it's the next free tty after 7 where X runs, 
         # and so open tries to use it.
         chmod 640 /dev/tty8
         chown $USER.root /dev/tty8
         # This does open up a tiny security hole: 
         #       user_a logs in with xdm, then logs out.
         #       user_b logs in at console.
         #       user_a can now redirect user_b to tty9 via the open command,
         #       and plop them down into some program that, perhaps, tries to
         #       persuade them to enter their password.
         
    

6.3 3Dfx "tweak" settings work in Linux too

You may have seen or heard mention of ways to "tweak" Quake's OpenGL performance by setting various environment variables. These variables are equally valid under Linux. You just set them slightly differently. If a Windows/DOS "tweak" guide tells you to:

     SET SST_GRXCLK=59
     

Under Linux, do it like this:

     export SST_GRXCLK=59
     

6.4 The Poor Man's Server Browser

Joe S. ( jszabo@eden.rutgers.edu) suggests:

     a trick I do with qstat:
     I make a file of my favorite servers, then do
     qstat -f /C/quake2/file.txt | less
     

hit control z to suspend, then copy the ip address or hostname I want with gpm to a command line like:

     ./quake2 +connect expert.eqclans.com
     
Then I can use fg to go back to the list later...

6.5 Using lib3dfxgl.so for Quake I

You can use the 3Dfx mini-driver (lib3dfxgl.so) from Quakeworld or Quake II with glquake too. Simply copy the glqwcl.3dfxgl or quake2.3dfxgl scripts to a new file, say glquake.3dfxgl. Then edit the glquake.3dfxgl script so it runs glquake instead of glqwcl. The same restrictions about running as root apply here, as do the differences between running under glibc and libc5. See the Quakeworld or Quake II sections for more information on lib3dfxgl.so.

6.6 Getting rid of that annoying "POSSIBLE SCAN CODE ERROR 57" message in GLQuake. ++

If you're sick of seeing that useless message every time you press the space bar in GLQuake, execute the following command from your quake directory and you'll never have to deal with it again. This little piece of Perl code just replaces the first character of the message with a null character, which signifies the end of a string in C programs. Now when GLQuake thinks it needs to tell us about a possible scan code error, it outputs an empty string instead! Oh, and your original glquake binary gets automatically backed up to glquake.bak too.

    perl -i.bak -0777pe 's/P(ossible unknown scancode)/\0$1/g' glquake
    

Thanks to Andrew Chase ( fixy@fixy.org) for this.


Next Previous Contents