Smooth Quake in Linux

From QWiki
Revision as of 21:55, 12 August 2021 by Ciscon (talk | contribs) (→‎Chrome/Chromium/Generic (XDG))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


WARNING: Page recently updated and not fully vetted, please consider talking to client developers before doing advanced changes to your system !!!

This page contains solutions and tips for various tearing, lagging, jerky and sucky Quake configurations, on Linux.

  • If you have low fps, try installing proprietary video drivers and disabling compositing (see compositing section below).
  • For minimal tearing set your framerate cap (cl_maxfps) above 1000, and for absolute minimum tearing set to a multiple of your refresh rate (e.g. 1001).
  • Some clients run much better than others under linux. Make sure you try ezQuake, fodQuake and FTE.


The recommendations in this section were suggested in October 2020 by United States ciscon:

nvidia-settings -a "[gpu:0]/GPUPowerMizerMode=1"
nvidia-settings -a OpenGLImageSettings=3
nvidia-settings -a SyncToVBlank=0
for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance | sudo tee $i

And put this into your ~/.profile: export __GL_YIELD="NOTHING"


Change mouse hz to 500/1000

Note: The usb polling rate will automatically be as high as possible on most modern usb controllers (ehci/xhci/etc) in recent linux kernels if the mouse properly advertises it's capabilities. It is still worth checking that it is actually running at the desired polling rate as some bios settings can prohibit the polling rate from going above a certain level and may need to be changed.

First and foremost check what your current rate is, it may very well already be at 500/1000 (depending on your mouse and usb controller limits):

The easy way:

The more direct way:

Download and compile evhz:

git clone
cd evhz
gcc evhz.c -o evhz

Run evhz and move mouse around, see that polling rate reaches desired/expected rate:

sudo ./evhz

Example output (500Hz mouse):

A..... G3: Latest   500Hz, Average   488Hz

If your mouse is not polling as fast as it should be, try forcing a polling rate in the usbhid module. This method will only work if you are using ehci (not xhci), but it is a way to force mice that do not advertise 500hz/1000hz polling rates but are capable of them to run at them. First, you must force your xhci controller into usb 2 mode, if you cannot do this in your BIOS, you can do it in linux:

As root:

lspci -nn | grep USB  | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0

To check current polling rate setting in usbhid, type in console:

cat /sys/module/usbhid/parameters/mousepoll

Using console, open /etc/modules in editor with admin rights:

sudo gedit /etc/modules

Add this two lines at the end:

-r usbhid
usbhid mousepoll=x

value "x" can be:

1 = 1000Hz 2 = 500Hz 4 = 250Hz 8 = 125Hz 10 = 100Hz (Default)

for example, to change polling rate to 500Hz, end lines in /etc/modules schould be:

-r usbhid
usbhid mousepoll=2

To test immediately without rebooting, type the following as a single command (otherwise you'll lose input on any usb devices you might have):

sudo rmmod usbhid;sudo modprobe usbhid mousepoll=2

Now run evhz again, if you are still not seeing the polling rate you're expecting it very well may be a bios setting. If you have any usb legacy or compatibility modes in your bios, disable them, this should fix the issue. Warning: disabling usb legacy/compatibility support in your bios may render your usb keyboard/mouse non-functional in grub, do not be alarmed if you cannot navigate the grub menu in this mode. It will still be usable before grub (eg bios) and after the linux kernel has loaded.

Warning: Higher polling rates will increase CPU usage.

Mouse related tools


Disable compositing:

Xorg has a built-in compositing extension which is enabled by default. Most window managers/desktop environments will provide a composite manager, most of which will automatically redirect fullscreen applications away from the compositor. This is not always the case however, and even when compositing is fully disabled in a composite manager, this redirect can fail. It is recommended that compositing be disabled in your composite manager (see your specific window manager/desktop environment's documentation, it should be a simple checkbox). If quake fails to be redirected properly, you will lose fps and things can appear jerky.

If you would like to completely disable the compositing extension in xorg just to be sure, just add the following file to your xorg.conf.d directory and restart x. Warning: if your window manager/desktop environment requires compositing, it may fail to start or may start a compatibility mode (eg KDE/Gnome):

sudo mkdir -p  sudo mkdir -p /etc/X11/xorg.conf.d
sudo vi /etc/X11/xorg.conf.d/01-compositor.conf


Section "Extensions"
    Option "COMPOSITE" "Disable"

Change your composite manager:

If you require a composite manager (or just can't live without compositing for some reason), use compton if you can. The default compositor for XFCE is very bad, it drops frames and causes vidlag. Disable XFCE's composite manager via "Settings Manager" and then "Window Manager Tweaks". You can add compton to your session startup via Settings Manager -> Session and Startup.

compton --unredir-if-possible

Run quake in a separate X Server:

Note: this will no longer work with systemd which most modern linux distributions unfortunately use.

Users have reported that running a second x server can give a more responsive quake (

Excerpt/Conclusion from the above link:

  • To run your engine in a second X server (which might help on various occasions) on virtual terminal 12 (you could switch between regular X and 2nd one by pressing ctl+alt+f7 and ctr+alt+f12):
xinit /path/to/your/executable_or_script -- :1 vt12
  • If you want you can also create a new xorg.conf for this new X server and specify it via attaching "-config xorg_qw.conf" in the command line.
xinit /path/to/your/executable_or_script -- :1 -config xorg_qw.conf

You can also simply type xinit -- :1 to get an console where you then start the game.

Refresh Rate If you are using a proprietary driver such as the nvidia driver or amdgpu-pro, you are most likely using the supplied control panel to configure your GPU settings and can set the appropriate refresh rate there. If not, you may need to do it manually. You can do this by setting it in an xorg configuration file, or do it on the fly using xrandr. Here we'll look at doing this via xrandr as it's more flexible and we can test changes immediately.

Run xrandr:


You should see output similar to:

Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
   1920x1080     60.00 + 144.00*  119.98    99.93  
   1440x900     119.85  
   1280x1024    119.96    75.02    60.02  
   1024x768     119.99    75.03    60.00  
   800x600      119.97    75.00    60.32    56.25  
   640x480      120.01    75.00    59.94  

This example output/monitor supports 144Hz and 1920x1080, and you can see that it is set to 1920x1080@144Hz as the asterisk (*) is next to 144 on the 1920x1080 line. You can change this by simply specifying whichever resolution/refresh rate you would like on any particular output:

xrandr --output DVI-I-1 --mode 1920x1080 --rate 120

This would change the refresh rate to ~120, example output of running xrandr with no options again would show that we have successfully changed our refresh rate:

Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
   1920x1080     60.00 + 144.00   119.98*   99.93  
   1440x900     119.85  
   1280x1024    119.96    75.02    60.02  
   1024x768     119.99    75.03    60.00  
   800x600      119.97    75.00    60.32    56.25  
   640x480      120.01    75.00    59.94  

You can always have this program run on start-up/login by using whichever method your window manager/desktop environment uses to autorun programs.

To set your refresh in an xorg configuration file, please see the Arch wiki on the subject:

CPU Affinity

(This shouldn't be necessary anymore, just use a newer kernel (5.x+) where scheduling has gotten much better.)

Normally the individual threads spawned by ezquake will be managed by the kernel and will be moved from one core to another as various conditions are met. While for most workloads this is fine, there is some inherent latency with this method, so we prefer to bind each thread to a physical core instead. You can see this default behavior by running ezquake and then running ps in a terminal:

watch -n .5 'ps -L -o pid,tid,%cpu,comm,psr -p `pgrep ezquake`'

The output should look something like the following:

15461 15461 40.0 ezquake-linux-x   3
15461 15462  0.0 PulseHotplug      3
15461 15463  0.4 SDLAudioP2        0

In this example the first row represents the main ezquake thread while the following rows indicate other threads it has spawned. The last column shows you which core each thread is running on. By running this command with watch as we have, we can see the threads being moved around.

If we want to bind each thread to a core, we can use the following bash script to do so once ezquake has been up and running for a few seconds:

#run quake and background
/path/to/quake/ezquake-linux-arch &
qpid=$(pgrep -f ezquake-linux-arch)

#allow threads to spawn
sleep 5

	#set thread affinity - sorted based on cpu usage so our primary threads will definitely get their own cores
	qthreads=$(ps --no-headers -L -o pcpu:1,tid:1 -p ${qpid}|sort -nr|cut -d" " -f2)
	#set affinity, if we run out of physical cores to pin threads to, let the system decide where they go
	for thread in $qthreads;do
		taskset -p -c $core $thread >/dev/null 2>&1
		let core=core+1 
wait $qpid

A maintained and fully featured version of this script is kept at

Other Common problems

Missing files error Unlike Windows, Linux is case-sensitive, which means "PaK0.pAk" and "pak0.pak" are different files. If you just copied the Quake directory from your Windows machine, it's possible that there are some files in upper case. Fortunately, that's easy to fix.

  • change to your main quake directory

e.g. 'cd /home/joe/quakeworld'

  • convert every file in your Quake directory (including all subdirectories) to lowercase, run this little script (by faustov@ryba):
#! /bin/bash

Cdir ()
for elem in * ; do
        if [[ -d "$elem" ]] ; then 
                mv "$elem" "$(echo $elem | sed -e 's/./\L&/g')" 2> /dev/null
                elem=$(echo $elem | sed -e 's/./\L&/g');
                cd "$elem";
                cd ..;
                mv "$elem" "$(echo $elem | sed -e 's/./\L&/g')" 2> /dev/null


Keyboard issues If you get laggy/skippy input from the keyboard when using high refresh rate mouse polling, you could try switching keyboard drivers if you want to keep the mouse the way it is. My keyboard frequently ignored my commands when using 1000hz evdev+ evdev keyboard, so I switched them to mouse/kbd X11 drivers and things seem okay now.

Launch ezQuake by clicking on qw:// links in your browser

Chrome/Chromium/Generic (XDG)

Create a new file at: ~/.local/share/applications/qw-url-handler.desktop:

[Desktop Entry]
GenericName=Handles qw:// protocol links from browsers
Comment=Browser Uses ezquake to open qw:// urls.
Exec=/path/to/quake/ezquake-linux-x86_64 +qwurl %u

Replacing /path/to/quake to your own directory structure.

Then register this entry as the default for the qw protocol:

xdg-mime default qw-url-handler.desktop x-scheme-handler/qw

Test with xdg-open:

xdg-open qw://serveraddresshere

Gnome (untested):

gconftool-2 -t string -s /desktop/gnome/url-handlers/qw/command exec /path/to/qw/ezquake-gl.glx +qwurl "%s"
gconftool-2 -t bool -s /desktop/gnome/url-handlers/qw/enabled true
gconftool-2 -t bool -s /desktop/gnome/url-handlers/qw/needs_terminal false 

Adapted from


Create a new file containing this:

# ezquake launcher script for qw:// links
exec /path/to/qw/ezquake-gl.glx +qwurl "$@"
  • Save it as and chmod +x it. Place it in your qw folder.
  • In Firefox go to about:config.
  • Rightclick, "new" -> "string": "" "/path/to/"
  • Rightclick, "new" -> "boolean": "network.protocol-handler.external.qw" "true"
  • Rightclick, "new" -> "boolean": "network.protocol-handler.warn-external.qw" "false" (unless you want that "are you sure" box)

Compile ezQuake yourself

You can use GIT to get the latest development sources and compile ezQuake yourself.


  • A working Internet connection
  • Installed software
    • git (package git)


OPTIONAL: Set your compiler flags for your system. This will result in a binary that will most likely not run on other systems, but will be optimized for your own. There is no reason not to do this if the resulting quake executable is only going to be used on this particular system as it will result in a performance increase of some kind.

export CFLAGS="-march=native -mtune=native -O3 -pipe"

  • change to your home directory
cd ~
  • checkout the code from git to folder ezquake
git clone git:// ezquake
  • cd into new source directory
cd ezquake
  • run build script

If everything went smoothly a new binary will exist in the source directory, ezquake-linux-x86_64 (on a 64 bit system for example)

Create Desktop Shortcut

Create a new .desktop file on your desktop (or wherever you'd like the shortcut), eg: ezQuake.desktop

[Desktop Entry]

Replacing /path/to/quake to your own directory structure.


Other OS


See Smooth Quake


If ezQuake doesn't work for you, feel free to try Fodquake