Installing and configuring a graphical display server

The client-server idea, which is the opposite way round from expectations

In X, the SERVER is the machine with the screen, keyboard and mouse, and the CLIENTS are the applications — even when they are on the same machine. That inversion is deliberate and it is what allows an application running on a remote host to draw on your local display: the DISPLAY variable names which server to draw on, spelled host:display.screen, and :0 means the first display on this machine.

X.Org is the implementation in use. Configuration is /etc/X11/xorg.conf if it exists, though modern systems autodetect nearly everything and use snippets in /etc/X11/xorg.conf.d/ for the few overrides needed. The log is /var/log/Xorg.0.log, and it is the right first place to look when the display does not come up.

Wayland is the replacement, and its structural difference is worth stating: it merges the display server and the window manager into one compositor, and there is no built-in network transparency, so a remote application does not simply set DISPLAY. On Wayland, X applications run through an X compatibility layer.

The pieces around it

A window manager draws the frames and decides where windows go; a desktop environment is a window manager plus a whole set of applications and settings. xhost and xauth control who may connect to a display — xhost by host, which is blunt, and xauth by a cookie file in ~/.Xauthority, which is what ssh -X uses when it forwards a display. xdpyinfo reports what the server is capable of.

The keyboard belongs to the server too, which is why changing its layout is not a shell setting. setxkbmap de talks to the XKB extension of the RUNNING server and switches the layout immediately — the first non-option argument is taken as the layout, so setxkbmap -layout de is the same instruction written out. Because it changes a running server, it lasts exactly as long as that server does. Making the layout survive a restart is a different file: an XkbLayout option in an InputClass section under /etc/X11/xorg.conf.d/, or localectl set-x11-keymap de on a systemd host, which writes that snippet for you. Keep localectl's two keymaps apart — the X11 one is this, and the console one is what loadkeys sets for a text terminal.

Pointing a client at a display

DISPLAY is an ordinary environment variable, so it is set the ordinary way and it has to be EXPORTED: export DISPLAY=:0 sets it for this shell and for everything the shell starts, which is the point, because the thing that needs to read it is the application you are about to launch. Setting it without export changes the shell and nothing it runs. Quoting makes no difference — export DISPLAY=":0" and export DISPLAY=:0 are the same — because there is nothing in the value for the shell to split on.

The value is host:display.screen, and the two shorter spellings mean the same thing on a single-screen machine: :0 is display 0 with the screen left implied, :0.0 says screen 0 explicitly. An empty host means this machine. So a cron job or a script run from a console that needs to put a window on the logged-in desktop sets DISPLAY first — and, because the server also checks the cookie, usually XAUTHORITY with it.

$ xtermxterm: Xt error: Can't open display: $ DISPLAY=:0$ xtermxterm: Xt error: Can't open display: # set in the shell, never passed to the child$ export DISPLAY=:0$ xterm# a window opens on the local display