- The X.Org project provides an open source implementation of the X Window System. The development work is being done in conjunction with the freedesktop.org community. The X.Org Foundation is the educational non-profit corporation whose Board serves this effort, and whose Members lead this work.
Xorg (commonly referred as simply X) is the most popular display server among Linux users. Its ubiquity has led to making it an ever-present requisite for GUI applications, resulting in massive adoption from most distributions. See the Xorg Wikipedia article or visit the Xorg website for more details.
- 1 Installation
- 2 Running
- 3 Configuration
- 4 Input devices
- 5 Monitor settings
- 6 Composite
- 7 Tips and tricks
- 8 Troubleshooting
- 8.1 General
- 8.2 Black screen, No protocol specified.., Resource temporarily unavailable for all or some users
- 8.3 DRI with Matrox cards stopped working
- 8.4 Frame-buffer mode problems
- 8.5 Program requests "font '(null)'"
- 8.6 Recovery: disabling Xorg before GUI login
- 8.7 X clients started with "su" fail
- 8.8 X failed to start: Keyboard initialization failed
- 8.9 Rootless Xorg
- 8.10 A green screen whenever trying to watch a video
- 8.11 SocketCreateListener error
- 8.12 Invalid MIT-MAGIC-COOKIE-1 key when trying to run a program as root
- 9 See also
Xorg can be installed with the package.
Additionally, some packages from thegroup are necessary for certain configuration tasks, they are pointed out in the relevant sections.
Finally, angroup is also available, which includes Xorg server packages, packages from the group and fonts.
The Linux kernel includes open-source video drivers and support for hardware accelerated framebuffers. However, userland support is required for OpenGL and 2D acceleration in X11.
First, identify your card:
$ lspci | grep -e VGA -e 3D
Then install an appropriate driver. You can search the package database for a complete list of open-source video drivers:
$ pacman -Ss xf86-video
Xorg searches for installed drivers automatically:
- If it cannot find the specific driver installed for the hardware (listed below), it first searches for fbdev ( ).
- If that is not found, it searches for vesa ( ), the generic driver, which handles a large number of chipsets but does not include any 2D or 3D acceleration.
- If vesa is not found, Xorg will fall back to kernel mode setting, which includes GLAMOR acceleration (see ).
In order for video acceleration to work, and often to expose all the modes that the GPU can set, a proper video driver is required:
|AMD / ATI||Open source||AMDGPU|
|Intel||Open source||Intel graphics|
Other video drivers can be found in thegroup.
Xorg should run smoothly without closed source drivers, which are typically needed only for advanced features such as fast 3D-accelerated rendering for games. The exceptions to this rule are recent GPUs (especially NVIDIA GPUs), that are not supported by the open source drivers.
|GPU architecture||Radeon cards||Open-source driver||Proprietary driver|
|GCN 3||AMDGPU||Catalyst /|
|GCN 2||AMDGPU* / ATI||Catalyst|
|GCN 1||AMDGPU* / ATI||Catalyst|
|TeraScale 2&3||HD 5000 - HD 6000||ATI||Catalyst|
|TeraScale 1||HD 2000 - HD 4000||Catalyst legacy|
|Older||X1000 and older||not available|
- *: Experimental
/usr/share/X11/xorg.conf.d/, and no extra configuration is necessary for most setups.
Xorg uses a configuration file called
xorg.conf and files ending in the suffix
.conf for its initial setup: the complete list of the folders where these files are searched can be found in , together with a detailed explanation of all the available options.
Using .conf files
/etc/X11/xorg.conf.d/ directory stores host-specific configuration. You are free to add configuration files there, but they must have a
.conf suffix: the files are read in ASCII order, and by convention their names start with
XX- (two digits and a hyphen, so that for example 10 is read before 20). These files are parsed by the X server upon startup and are treated like part of the traditional
xorg.conf configuration file. Note that on conflicting configuration, the file read last will be processed. For that reason the most generic configuration files should be ordered first by name. The configuration entries in the
xorg.conf file are processed at the end.
For option examples to set, see also the Fedora wiki.
Xorg can also be configured via
/etc/xorg.conf. You can also generate a skeleton for
# Xorg :0 -configure
This should create a
xorg.conf.new file in
/root/ that you can copy over to
Xorg :2 -configure.
For input devices the X server defaults to the libinput driver (), but and related drivers are available as alternative.
Udev, which is provided as a systemd dependency, will detect hardware and both drivers will act as hotplugging input driver for almost all devices, as defined in the default configuration files
40-libinput.conf in the
After starting X server, the log file will show which driver hotplugged for the individual devices (note the most recent log file name may vary):
$ grep -e "Using input driver " Xorg.0.log
If both do not support a particular device, install the needed driver from thegroup. The same applies, if you want to use another driver.
To influence hotplugging, see #Configuration.
See Mouse acceleration.
See Mouse buttons.
- Newer versions of Xorg are auto-configuring, so manual configuration should not be needed.
- If Xorg is unable to detect any monitor or to avoid auto-configuring, a configuration file can be used. A common case where this is necessary is a headless system, which boots without a monitor and starts Xorg automatically, either from a virtual console at login, or from a display manager.
For a headless configuration the install it and create a configuration file, such as the following:driver is necessary;
Section "Monitor" Identifier "dummy_monitor" HorizSync 28.0-80.0 VertRefresh 48.0-75.0 Modeline "1920x1080" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 EndSection Section "Device" Identifier "dummy_card" VideoRam 256000 Driver "dummy" EndSection Section "Screen" Identifier "dummy_screen" Device "dummy_card" Monitor "dummy_monitor" SubSection "Display" EndSubSection EndSection
See main article Multihead for general information.
See also GPU-specific instructions:
- NVIDIA#Multiple monitors
- Nouveau#Dual head
- AMD Catalyst#Double Screen (Dual Head / Dual Screen / Xinerama)
- ATI#Multihead setup
More than one graphics card
You must define the correct driver to use and put the bus ID of your graphic cards.
Section "Device" Identifier "Screen0" Driver "nouveau" BusID "PCI:0:12:0" EndSection Section "Device" Identifier "Screen1" Driver "radeon" BusID "PCI:1:0:0" EndSection
To get your bus ID:
$ lspci | grep VGA
01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9600M GT] (rev a1)
The bus ID here is 1:0:0.
Display size and DPI
The DPI of the X server is determined in the following manner:
-dpicommand line option has highest priority.
- If this is not used, the
DisplaySizesetting in the X config file is used to derive the DPI, given the screen resolution.
- If no
DisplaySizeis given, the monitor size values from DDC are used to derive the DPI, given the screen resolution.
- If DDC does not specify a size, 75 DPI is used by default.
In order to get correct dots per inch (DPI) set, the display size must be recognized or set. Having the correct DPI is especially necessary where fine detail is required (like font rendering). Previously, manufacturers tried to create a standard for 96 DPI (a 10.3" diagonal monitor would be 800x600, a 13.2" monitor 1024x768). These days, screen DPIs vary and may not be equal horizontally and vertically. For example, a 19" widescreen LCD at 1440x900 may have a DPI of 89x87. To be able to set the DPI, the Xorg server attempts to auto-detect your monitor's physical screen size through the graphic card with DDC.
When the Xorg server knows the physical screen size, it will be able to set the correct DPI depending on resolution size.
To see if your display size and DPI are detected/calculated correctly:
$ xdpyinfo | grep -B2 resolution
Check that the dimensions match your display size. If the Xorg server is not able to correctly calculate the screen size, it will default to 75x75 DPI and you will have to calculate it yourself.
If you have specifications on the physical size of the screen, they can be entered in the Xorg configuration file so that the proper DPI is calculated (adjust identifier to your xrandr output) :
Section "Monitor" Identifier "DVI-D-0" DisplaySize 286 179 # In millimeters EndSection
If you only want to enter the specification of your monitor without creating a full xorg.conf create a new config file. For example (
Section "Monitor" Identifier "<default monitor>" DisplaySize 286 179 # In millimeters EndSection
If you do not have specifications for physical screen width and height (most specifications these days only list by diagonal size), you can use the monitor's native resolution (or aspect ratio) and diagonal length to calculate the horizontal and vertical physical dimensions. Using the Pythagorean theorem on a 13.3" diagonal length screen with a 1280x800 native resolution (or 16:10 aspect ratio):
$ echo 'scale=5;sqrt(1280^2+800^2)' | bc # 1509.43698
This will give the pixel diagonal length and with this value you can discover the physical horizontal and vertical lengths (and convert them to millimeters):
$ echo 'scale=5;(13.3/1509)*1280*25.4' | bc # 286.43072 $ echo 'scale=5;(13.3/1509)*800*25.4' | bc # 179.01920
Setting DPI manually
For RandR compliant drivers (for example the open source ATI driver), you can set it by:
$ xrandr --dpi 144
To make it permanent, see Autostarting#On Xorg startup.
Proprietary NVIDIA driver
DPI can be set manually if you only plan to use one resolution (DPI calculator):
Section "Monitor" Identifier "Monitor0" Option "DPI" "96 x 96" EndSection
You can manually set the DPI adding the options below on
/etc/X11/xorg.conf.d/20-nvidia.conf (inside Device section):
Option "UseEdidDpi" "False" Option "DPI" "96 x 96"
Manual DPI Setting Caveat
GTK very often overrides the server's DPI via the optional Xresource
Xft.dpi. To find out whether this is happening to you, check with:
$ xrdb -query | grep dpi
With GTK library versions since 3.16, when this variable is not otherwise explicitly set, GTK sets it to 96. To have GTK apps obey the server DPI you may need to explictly set Xft.dpi to the same value as the server. The Xft.dpi resource is the method by which some desktop environments optionally force DPI to a particular value in personal settings. Among these are KDE and TDE.
Display Power Management
DPMS (Display Power Management Signaling) is a technology that allows power saving behaviour of monitors when the computer is not in use. This will allow you to have your monitors automatically go into standby after a predefined period of time.
The Composite extension for X causes an entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. Applications can then take the contents of that buffer and do whatever they like. The off-screen buffer can be automatically merged into the parent window or merged by external programs, called compositing managers. See the following article for more information: compositing window manager
List of composite managers
- Compton — Compositor (a fork of xcompmgr-dana)
- Xcompmgr — Composite window-effects manager
- Unagi — Modular compositing manager which aims written in C and based on XCB
Tips and tricks
This section lists utilities for automating keyboard / mouse input and window operations (like moving, resizing or raising).
|xautomation||Yes||No||Also contains screen scraping tools. Cannot simulate F13+.|
|xdo||AUR||No||Yes||Small X utility to perform elementary actions on windows.|
|xdotool||Yes||Yes||Very buggy and not in active development, e.g: has broken CLI parsing.|
|xvkbd||AUR||Yes||No||Virtual keyboard for Xorg, also has the |
Nested X session
To run a nested session of another desktop environment:
$ /usr/bin/Xnest :1 -geometry 1024x768+0+0 -ac -name Windowmaker & wmaker -display :1
This will launch a Window Maker session in a 1024 by 768 window within your current X session.
This needs the packageto be installed.
Starting GUI programs remotely
See main article: OpenSSH#X11 forwarding.
On-demand disabling and enabling of input sources
With the help of xinput you can temporarily disable or enable input sources. This might be useful, for example, on systems that have more than one mouse, such as the ThinkPads and you would rather use just one to avoid unwanted mouse clicks.
Install the package.
Find the name or ID of the device you want to disable:
For example in a Lenovo ThinkPad T500, the output looks like this:
⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ TPPS/2 IBM TrackPoint id=11 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=10 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=9 [slave keyboard (3)] ↳ ThinkPad Extra Buttons id=12 [slave keyboard (3)]
Disable the device with
xinput --disable device, where device is the device ID or name of the device you want to disable. In this example we will disable the Synaptics Touchpad, with the ID 10:
$ xinput --disable 10
To re-enable the device, just issue the opposite command:
$ xinput --enable 10
Alternatively using the device name, the command to disable the touchpad would be:
$ xinput --disable "SynPS/2 Synaptics TouchPad"
Killing application with hotkey
Run script on hotkey:
#!/bin/bash windowFocus=$(xdotool getwindowfocus); pid=$(xprop -id $windowFocus | grep PID); kill -9 $pid
Block TTY access
To block tty access when in an X add the following to xorg.conf:
Section "ServerFlags" Option "DontVTSwitch" "True" EndSection
Prevent a user from killing X
To prevent a user from killing when it is running add the following to xorg.conf:
Section "ServerFlags" Option "DontZap" "True" EndSection
The logfiles are of the form
n being the display number. For a single user machine with default configuration the applicable log is frequently
Xorg.0.log, but otherwise it may vary. To make sure to pick the right file it may help to look at the timestamp of the X server session start and from which console it was started. For example:
$ grep -e Log -e tty Xorg.0.log
[ 40.623] (==) Log file: "/home/archuser/.local/share/xorg/Xorg.0.log", Time: Thu Aug 28 12:36:44 2014 [ 40.704] (--) controlling tty is VT number 1, auto-enabling KeepTty
- In the logfile then be on the lookout for any lines beginning with
(EE), which represent errors, and also
(WW), which are warnings that could indicate other issues.
- If there is an empty
.xinitrcfile in your
$HOME, either delete or edit it in order for X to start properly. If you do not do this X will show a blank screen with what appears to be no errors in your
Xorg.0.log. Simply deleting it will get it running with a default X environment.
- If the screen goes black, you may still attempt to switch to a different virtual console (e.g.
Ctrl+Alt+F6), and blindly log in as root. You can do this by typing
Enterafter typing it) and entering the root password (again, press
Enterafter typing it).
- You may also attempt to kill the X server with:
# pkill -x X
- If this does not work, reboot blindly with:
- Check specific pages in Category:Input devices if you have issues with keyboard, mouse, touchpad etc.
- Search for common problems in ATI, Intel and NVIDIA articles.
X creates configuration and temporary files in current user's home directory. Make sure there is free disk space available on the partition your home directory resides in. Unfortunately, X server does not provide any more obvious information about lack of disk space in this case.
DRI with Matrox cards stopped working
If you use a Matrox card and DRI stopped working after upgrading to Xorg, try adding the line:
Option "OldDmaInit" "On"
to the Device section that references the video card in
Frame-buffer mode problems
If X fails to start with the following log messages,
(WW) Falling back to old probe method for fbdev (II) Loading sub module "fbdevhw" (II) LoadModule: "fbdevhw" (II) Loading /usr/lib/xorg/modules/linux//libfbdevhw.so (II) Module fbdevhw: vendor="X.Org Foundation" compiled for 1.6.1, module version=0.0.2 ABI class: X.Org Video Driver, version 5.0 (II) FBDEV(1): using default device Fatal server error: Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
Uninstall the package.
Program requests "font '(null)'"
unable to load font `(null)'.
Some programs only work with bitmap fonts. Two major packages with bitmap fonts are available,
xdpyinfo from , like this:
$ xdpyinfo | grep resolution
and use what is closer to the shown value.
Recovery: disabling Xorg before GUI login
If Xorg is set to boot up automatically and for some reason you need to prevent it from starting up before the login/display manager appears (if the system is wrongly configured and Xorg does not recognize your mouse or keyboard input, for instance), you can accomplish this task with two methods.
- Change default target to rescue.target. See systemd#Change default target to boot into.
- If you have not only a faulty system that makes Xorg unusable, but you have also set the GRUB menu wait time to zero, or cannot otherwise use GRUB to prevent Xorg from booting, you can use the Arch Linux live CD. Follow the installation guide about how to mount and chroot into the installed Arch Linux. Alternatively try to switch into another tty with
Ctrl+Alt+ function key (usually from
F7depending on which is not used by X), login as root and follow steps below.
Depending on setup, you will need to do one or more of these steps:
- Disable the display manager.
- Disable the automatic start of the X.
- Rename the
~/.xinitrcor comment out the
execline in it.
X clients started with "su" fail
If you are getting "Client is not authorized to connect to server", try adding the line:
session optional pam_xauth.so
pam_xauth will then properly set environment variables and handle
X failed to start: Keyboard initialization failed
If the filesystem (specifically
/tmp) is full,
startx will fail.
/var/log/Xorg.0.log will end with:
(EE) Error compiling keymap (server-0) (EE) XKB: Could not compile keymap (EE) XKB: Failed to load keymap. Loading default keymap instead. (EE) Error compiling keymap (server-0) (EE) XKB: Could not compile keymap XKB: Failed to compile keymap Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. Fatal server error: Failed to activate core devices. Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. (II) AIGLX: Suspending AIGLX clients for VT switch
Make some free space on the relevant filesystem and X will start.
- Starting X via xinit; display managers are not supported
- Kernel mode setting; implementations in proprietary display drivers fail auto-detection and require manually setting
needs_root_rights = noin
If you do not fit these requirements, re-enable root rights in
needs_root_rights = yes
While user Xorg logs are stored in
~/.local/share/xorg/Xorg.log, they do not include the output from the X session. To re-enable redirection, start X with the
exec startx -- -keeptty > ~/.xorg.log 2>&1
~/.xserverrc, and append
-keeptty. See .
A green screen whenever trying to watch a video
Your color depth is set wrong. It may need to be 24 instead of 16, for example.
If X terminates with error message "SocketCreateListener() failed", you may need to delete socket files in
/tmp/.X11-unix. This may happen if you have previously run Xorg as root (e.g. to generate an
Invalid MIT-MAGIC-COOKIE-1 key when trying to run a program as root
That error means that only the current user has access to the X server. The solution is to give access to root:
$ xhost +si:localuser:root
That line can also be used to give access to X to a different user than root.