Page Body

GNU/Linux User Interfaces and Desktops

Table of Contents

A GNU/Linux system provides two interfaces for user interaction, a command line interface (CLI) and a graphical user interface (GUI).

Note: If you are not familiar with the GNU/Linux command line interface, review the Conventions page before proceeding.

Command Line Interface (CLI)

The Linux kernel invokes the getty program for every user terminal, which brings up a login prompt. When the getty program receives input from the user, it invokes the login program.

The login program verifies the identity of the user by checking the /etc/passwd file. If either the account username or password are not correct, a Login incorrect message appears, but only after both the username and password have been entered. This makes it harder for a malicious actor to guess valid usernames.

If the user fails to provide a valid password, the login program returns control back to the getty program. If the user enters a valid password, the login program takes the user to the shell prompt.

X Window System (X11, X) Graphical User Interface (GUI)

At the end of the boot process, the system's display manager starts the:

  1. X Window System (X11, X)
  2. Graphical system login
  3. Desktop environment (if the prior login was successful)

A Desktop Environment (or Desktop, for short) is defined by:

  • Session Manager - Starts and maintains the components of the graphical session. It is given control of a session via the display manager.
  • Window Manager - Controls the placement and movement of windows, window title-bars, and controls.
  • File Manager
  • Control Panel/Control Center
  • Integrated Office Suite
  • Media Players
  • Common Look and Feel

Never log into the GUI as the root user, as this will cause all graphical applications (including the X Server) to run with root privileges.

All display managers should be able to handle graphical logins for all desktop environments. The display manager your system uses depends on which GNU/Linux distribution you have chosen and how it is configured.

Terminology

Desktop Environment
Desktop environments, like KDE Plasma or GNOME, sit on top of X11. They try to enforce (separate) uniform standards for the appearance and behavior of programs, as well as offer programs that implement these standards in order to provide a comfortable and consistent user experience.
The desktop environments do not preclude each other. If you are working in one desktop environment, but would like to use a program that was written for a different desktop environment, you can. There are common standards for various basic functions like cutting and pasting pieces of text that are supported by all desktop environments, and facilitate mixing and matching.
Most desktop environments rely on specific toolkits (e.g., KDE Plasma on QT, GNOME on GTK+). This means that if you plan to develop software that is meant for a particular desktop environment, you should use the toolkit in question to enable the best possible integration.
Display Manager
A program that manages the X server (or X servers) on a computer. The display manager allows users to log in using a graphical environment and subsequently constructs a graphical session for them. Many display managers also support session management, i.e., they try to save the current state of the session when the user logs out and reconstruct it when the user logs in again.
How well session management works in practice depends on how thoroughly the X11 clients go along with it. Not all clients manage this well, and many clients need to deal with very complex internal states that are not easy to save and restore.
Toolkit
A programming environment for X11 clients. Toolkits provide programmers with the means to describe the graphical output of a program, how it deals with the graphical output of a program, and how it deals with events like mouse clicks and key presses. Then, this functionality is mapped to X protocol messages by the toolkit.
The main advantage of a toolkit is that, as a programmer, you do not need to deal with the primitive X11 operations, but can write code that is convenient in a high-level programming language. There are various toolkits, some of which are optimized for particular programming languages (like C and C++), and some of which allow programming in other languages (like Python).
Window Manager
A special X11 client whose job it is to control the placement (position and foreground/background) of windows on the screen. Clients may make suggestions, but the window manager has the last word. There are various window managers with differing philosophies. Now, many window managers also double as compositors for 3D graphics.
Popular Window Managers include:

To change your default window manager, you can use the update-alternatives command:

update-alternatives --config x-window-manager

If you have alternate window managers installed, the above command should show them and allow you to interactively select which one to use. Run man 1 update-alternatives for more information.

The X Window System (X11, X) Philosophy

The X Window System (X11, X) is a graphics environment developed at MIT from 1984 to 1987. The basis of X11 is the X protocol, a method of transmitting basic graphics operations across a network connection.

X11 is a client-server system, but with one important difference. The X server runs on a desktop computer and X clients (i.e., application programs) send graphics commands to it via the X protocol. Conversely, the X server sends events like key presses and mouse movements to the X clients.

Usually, on GNU/Linux, X11 clients and the X server exchange X protocol messages using UNIX domain sockets (i.e., fast interprocess connections between programs on the same computer). However, X protocol messages can be transported via Transmission Control Protocol/Internet Protocol (TCP/IP) to other computers on the network. Therefore, X11 clients can run on computers that do not contain graphics hardware, as long as they can talk to an X server on another computer via the network.

The X protocol operations are fairly trivial. It supports simple graphics operations (e.g., drawing dots, lines, circles, rectangles or character strings). In addition, there are functions to manage windows (i.e., rectangular screen areas that can be the target of events like mouse clicks or key presses) and for internal organization.

If an application presents a pop-up menu, the X server must report a click on the menu's button to the application. The application then sends the graphics commands necessary to render the menu and takes over the user interaction, being fed a constant stream of mouse movement messages by the X server, until the user decides on a menu item. This low-level interaction between server and application has often been criticized.

It is possible to move more of this interaction into the X server. So far, the X11 philosophy is that the server offers graphics operations, but does not regulate their use (i.e., mechanism, not policy).

X.Org

The X.Org Server is the version of the X Window System used in GNU/Linux. Like X11, X.Org is a set of software that provides the basis for a GUI (i.e., basic window features and the means to interface with hardware). X.Org provides the standard toolkit and protocol to build graphical interfaces on nearly all GNU/Linux systems.

Serious computer graphics today means 3D graphics, even if what is displayed does not look three-dimensional. Ideally, applications can, with some help from X.Org, talk directly to specialized 3D hardware on the graphics chip to create graphics effects at high speed. Less than ideally, parts of the 3D graphics are computed by the Central Processing Unit (CPU).

For the ideal case, you need a kernel driver for your graphics chip and another driver for X.Org. The former takes care of basic graphics configuration and low-level operations. The latter handles the operations in the X protocol.

Generally speaking, Intel graphics hardware is best supported by GNU/Linux and X.Org (various germane developers work for Intel). However, as 3D performance is concerned, Intel is usually not considered to produce graphics hardware in the same league as the best graphics chips by AMD and nVidia. For the AMD and nVidia offerings, there are both freely available drivers, as well as proprietary drivers distributed by the manufacturers themselves, which have better hardware support, but are not available as source code.

X11 does not include 3D graphics operations, so the help that X.Org can provide to 3D clients usually amounts to making some graphics memory available to the client in which it can draw its output using direct 3D operations, typically using a graphics language like OpenGL. A special X11 client, the compositor, takes care of stacking the graphics output of various clients in the correct order and adorning it with effects like transparency and drop shadows.

The X Protocol

The logical separation between the X server and X clients by way of the X protocol allows the server and clients to run on separate machines. On the same computer, you can theoretically start various clients that in turn communicate with different X servers. The X11 clients figure out which server to talk to by means of the DISPLAY environment variable.

DISPLAY=janeway.example.com:0

The :0 at the end of the above command denotes the first X server on a computer. janeway.example.com:0 is also referred to as a display name. If you address an X server this way, it means that you want to communicate with it using TCP/IP (the X server listens to connections on port 6000).

If you would rather connect using a UNIX domain socket (which is preferable when the server and client are running on the same machine), use the names unix:0, unix:1, etc., which is equivalent to pick the fastest local connection method. On GNU/Linux, this typically amounts to a UNIX domain socket, but other UNIX operating systems may support additional transport mechanisms (e.g., shared memory).

In principle, nothing prevents you from running more than one X server on the same computer. Today, there are cheap port extenders with connections for a keyboard, a mouse, and a monitor, which are connected to a computer via Universal Serial Bus (USB). This allows you to have more than one user working on the same computer. In such cases, there will be one X server per head.

On top of addressing an X server on a computer, you can even address a screen that is controlled by that X server by adding a dot and the screen number, e.g., janeway.example:0.0 for the first screen of the first X server on janeway.

X servers have rudimentary access control and many do not listen for direct TCP connections. Otherwise, anyone who can listen in to the data traffic between the client and server would be able to visualize what the client draws on the screen. Today, the preferred method is to allow local connections only and enable remote access by means of X11 forwarding via the Secure Shell (SSH).

Besides the DISPLAY environment variable, most clients let you select the server on their command line using an option like -display, e.g., xclock -display 'janeway.example.com:0'. If you log in using a graphical environment, the DISPLAY variable should be correctly set on your behalf.

X.Org can be started from the command line with the # startx command. This command makes a few initializations and then invokes another program, xinit, which does the work to arrange for the launch of the X server and initial X11 clients. You can also specify a server number when invoking startx (e.g., startx -- :1 lets you start a second X server).

You can use the ${HOME}/.xinitrc and /etc/X11/xinit/xinitrc files to start X11 clients. All X11 clients must be launched to the background by putting an & at the end of the command line. Only the final X11 client, usually the window manager (e.g., Mutter), must be started in the foreground. If this final process is terminated, xinit stops the X server.

This is a simple ${HOME}/.xinitrc file:

# A terminal
xterm -geometry 80x40+10+10 &
# A clock
xclock -update 1 -geometry -5-5 &
# The window manager
fvwm2

The -geometry option is used to specify beforehand where windows should appear. The value of -geometry consists of an optional size specification (usually in pixels, but for programs like xterm, in characters), followed by an optional position specification. Both specifications are optional, but you should likely have at least one of the two.

The position specification consists of an x and y coordinate, where positive numbers count from the left or top edge of the screen, while negative numbers count from the right or bottom edge.

The easiest way to tell if your system's graphics system is supported by X.Org is to test it using a live GNU/Linux distribution. If you end up with a graphical environment, then you should be fine.

Current versions of X.Org can determine what hardware they need to deal with both inside the computer and as the monitor, and what the optimal parameters are like. You can still manually override these settings, but this is only necessary in exceptional cases.

If the X server does not correctly start, your first step should be to look at its log file, which is usually found in /var/lib/gdm3/.local/share/xorg/ (the location of the log file will depend on your distribution and its configuration). The X server uses this for a detailed report on the hardware it recognizes, and the drivers and settings it allocates.

/etc/X11/xorg.conf

The X.Org central configuration file is located at /etc/X11/xorg.conf. If you do not have this file on your system, you will need to do one of the following:

  • Switch to a virtual console (not a terminal emulator in a GUI), log in as the root user, and run the following commands:

    # '/etc/init.d/gdm' stop ||
    '/etc/init.d/gdm3 stop' ||
    '/etc/init.d/kdm stop' ||
    '/etc/init.d/xdm stop' ||
    '/etc/init.d/lightdm stop'
$ cd '/etc/X11'
# Xorg -configure

  • Reboot your machine into single user mode and run:

    $ cd '/etc/X11'
# Xorg -configure

For both options, follow the on-screen instructions.

/etc/X11/xorg.conf consists of separate sections, each of which starts with the Section keyword and ends with the End-Section keyword. Some sections, in particular those describing input and output devices, can occur multiple times. This allows you to, for example, use a mouse and touchpad at the same time. Inside the configuration file, case is irrelevant, except when specifying filenames.

Blank lines are ignored and comment lines start with #. Lines with actual settings may be indented in order to make the file structure clearer.

The most commonly used sections include:

Device

Device determines which graphics card the server should use. This section may occur several times.

The following is a minimal configuration using the VGA driver:

Section "Device"
  Identifier "Standard VGA"
  Driver "vga"
EndSection

This example is for an nVidia graphics card using the proprietary driver:

Section "Device"
  Identifier "Device0"
  Driver "nvidia"
  VendorName "NVIDIA Corporation"
  BoardName "NVS 3100M"
EndSection

If the system contains several graphics cards, you should use the BusID directive to specify the desired card's PCI address in order to avoid confusion. You can find the correct PCI address using the lspci command:

$ lspci | grep 'VGA compatible'
01:00.0 VGA compatible controller: NVIDIA Corporation GT218M

Extensions

Extensions lets you specify which X11 protocol extension should be enabled or disabled.

Section "Extensions"
  Option "MIT-SHM" "Enable"
  Option "Xinerama" "Disable"
EndSection

The names of extensions must be given using the correct capitalization. You can generate a list of extensions using a command like # Xorg -extension ?.

Files

Files tells the X server where to find the files it needs to do its job.

FontPath

FontPath denotes directories that the X server searches for fonts or a font server. Usually, there are many font directories and many FontPath directives.

InputDevice

InputDevice configures the X server with the input devices it should use. Every InputDevice section configures one input device like a mouse or keyboard. The section may occur several times:

This is a typical entry for a modern PC keyboard:

Section "InputDevice"
  Identifier "Keyboard1"
  Driver "Keyboard"
  Option "XkbLayout" "us"
  Option "XkbModel" "pc105"
EndSection

The individual options have the following meanings:

Driver
Load a module (driver) from the ModulePath.
Identifier
Give the section a name, so that it can be mentioned in a ServerLayout section.
XkbLayout
Enable a US English-language layout.
XkbModel
Define a standard (105-key) international PC keyboard.

If the AutoAddDevices server flag is set (the normal case), you do not need an InputDevice section, since the X server will automatically recognize the input devices. A more detailed configuration is only required if, for example, the X server is not supposed to actually use all of the available input devices.

In older configuration files, you may sometimes still find the Keyboard or Pointer sections. These names are deprecated. Use InputDevice instead.

Modes

Modes is an optional section (which may also occur several times) that lets you specify your monitor's display parameters in great detail.

Section "Monitor"
  UseModes "Mode1"
EndSection

Section "Modes"
  Identifier "Mode1"
  Modeline "800x600" 48.67 800 816 928 1072 600 600 610 626
  Modeline "640x480"
EndSection

The UseModes directive in Monitor points to the Modes section that is to be used. You may also place Modeline entries directly within the Monitor section, or use the less compact Mode subsections either there or within a Modes section.

You can determine what the mode definitions mean by running man 5 xorg.conf.

Module

Module lists the hardware-dependent X server modules that should be loaded (e.g., to support specific font types) or to enable particular features, like direct video rendering.

Section "Module"
  Load "dri"
  Load "v4l"
EndSection

The specific selection of modules depends on the X server. Usually, the list does not need to be changed. Also, it can be entirely omitted, in which case the X server will fetch whichever modules it needs.

If they exist, the extmod, dbe, dri, dri2, glx, and record modules will be automatically loaded. If that is not desired, you need to disable them using directives like Disable 'dbe'. In every case, extmod should be loaded.

ModulePath

ModulePath describes directories containing extension modules for X.Org. This is typically /usr/lib/xorg/modules/, as well as its subdirectories drivers, extensions, input, internal, and multimedia, if available.

Monitor

Monitor describes the properties of the display device in use.

Section "Monitor"
  Identifier "Monitor0"
  HorizSync 30-90
  VertRefresh 50-85
EndSection

Like the InputDevice section, the Monitor section needs an Identifier to be able to be referenced in ServerLayout sections. The horizontal and vertical frequencies may be found in the monitor's documentation.

RBGPath

RGBPath was used to name a file containing all of the color names known to the X server together with the corresponding RGB (red/green/blue) values. The conventional name is /etc/X11/rgb.txt, and this file is still a part of many GNU/Linux distributions to let you look up valid color names.

You can use color names whenever X11 clients let you specify colors (e.g., xterm -fg GoldenRod -bg NavyBlue). If the desired color is not mentioned in the file by name, you can also specify it as a hexadecimal number (a leading # denotes a RGB color).

In principle, nothing keeps your from adding your own favorite colors to the file. However, you should not remove any of the existing colors, nor change them too radically, since some programs may rely on their presence.

This is a heavily abridged example:

Section "Files"
ModulePath "/usr/lib/xorg/modules"
# RGBPath "/usr/share/X11/rgb.txt"  # no longer supported
FontPath "/usr/share/fonts/X11/misc:unscaled"
EndSection

Screen

Screen connects a graphics card and a monitor.

Section "Screen"
  Identifier "Screen0"
  Device "Device0"
  Monitor "Monitor0"
  DefaultDepth 24
  SubSection "Display"
    Depth 24
    Modes "1280x720"
  EndSubSection
  SubSection "Display"
    Depth 24
    Modes "1600x900"
  EndSubSection
EndSection

The subsections, called Display, determine various combinations of color depths and resolutions, between which you can switch at runtime using Ctrl+Alt++ or Ctrl+Alt+-. Possibly, you may have a DRI section that can contain settings for direct access to the graphics hardware by the X server.

ServerFlags

ServerFlags influences the X server's behavior. Individual options are set using the Option directive and may be overridden with the ServerLayout section, or on the command line when the server is started.

Section "ServerFlags"
  Option "BlankTime" "10" Screen saver after 10 minutes
EndSection

Some important server flags include:

AutoAddDevices
Specify whether keyboards, mice, and similar input devices should be automatically recognized by means of udev. This is enabled by default.
DefaultServerLayout
Specify which arrangement of graphics cards, monitors, keyboard, and mice should be used by default. Points to a ServerLayout section. Other server layouts may be selected from the command line.
DontZap
If this option is enabled (the default case), the server cannot be terminated using the Ctrl+Alt+Del key combination.

Most options are switches that can assume values like 1, true, yes, on, or 0, false, no, off. If you specify no value at all, true is assumed. You can also prepend a No to the option name, which means no:

Option "AutoAddDevices" "1"  # Enable option
Option "AutoAddDevices" "off"  # Disable option
Option "AutoAddDevices"  # Enable option
Option "NoAutoAddDevices"  # Disable option

Other options have values that could be integers or strings. All values must be placed inside quotes.

ServerLayout

ServerLayout describes the total configuration of the server, including input and output devices. This is what you would use to specify the arrangement of multiple monitors.

Section "ServerLayout"
  Identifier "Layout0"
  Screen 0 "Screen0" 0 0
  InputDevice "Keyboard0" "CoreKeyboard"
  InputDevice "Mouse0" "CorePointer"
  Option "Xinerama" "0"
EndSection

You need one Screen directive for every monitor that you are using. The first zero is the screen number, which must be contiguously assigned starting from zero (it can be omitted, in which case the screens will be numbered in the order of their appearance).

After the name of a Screen section, which must occur elsewhere in the file, there is a position specification, where 0 0 merely means that the upper left corner of this screen should correspond to the (0,0) coordinate. X11 coordinates increase to the right and downwards.

If the Xinerama option is enabled, all Screens will be considered as fragments of one large logical screen whose size is adequate to fit all Screens. The individual Screens must be configured to have the same color depth. The resolution must not be identical.

For example, you could have a primary monitor with 1920x1080 pixels, and also connect an LCD projector with 1024x768 pixels with something like this:

Screen 0 "LaptopDisplay" 0 0
Screen 1 "Projector" RightOf "LaptopDisplay"
Option "Xinerama" "Enable"

Then, you will have a logical screen with a width of 2944 pixels and a height of 1080 pixels, where the top edges of both screens are aligned with each other.

In the example above, there is a dead strip of 1024x312 pixels that is theoretically present (X11 can only handle rectangular screens, whether physical or logical), but cannot really be used. Specifically, new windows may not be automatically placed entirely within the dead strip, since you cannot drag them from there to a visible part of the screen. For sync situations, make sure to use a window manager that supports Xinerama and ensures that such things will not happen.

The monitors within the Screen lines may overlap (e.g., it is often useful if a projector for a presentation shows the upper left corner of the laptop display). To do so, it is best to specify the position of the extra screen using absolute numbers:

Screen 0 "LaptopDisplay" 0 0
Screen 1 "Projector" 64 0  # Leave room for left-edge control panel
Option "Xinerama" "Enable"

You may include several ServerLayout sections in your configuration file and pick one of those by means of the -layout option when directly starting the X server. For example, this can be used to have several configurations for the external video connector on a laptop computer.

Within the ServerLayout section, you may also include options from the ServerFlags section, which will then only apply to that particular configuration.

Section Summary

At the highest level are the ServerLayout sections. These name input and output devices belonging to the configuration.

The ServerLayout section refers to InputDevice and Screen sections elsewhere in the configuration file. A Screen consists of a graphics card (Device) and an associated monitor (Monitor).

The Files, ServerFlags, Module, and DRI sections apply to the X server as a whole.

The X Protocol and Fonts

The X protocol contains not just operations for drawing points, lines, and other geometrical shapes, but also for displaying text. Traditionally, the X server offered a selection of fonts. The client could query which fonts existed, and then specify which font should be used to display text at what position on the screen. Obtaining the font data and displaying the text were the server's job.

Now, X.Org and the common toolkits support the XRENDER extension which, among other things, can handle transparency to allow antialiasing. In turn, this enables the display of scalable fonts with smooth edges and is necessary for high-quality text output. With XRENDER, the X11 operations for text display are entirely avoided.

Instead, the client can upload glyphs (i.e., letters, digits, and other characters) and use these for rendering text. The fonts offered by the X server are unimportant for XRENDER, since the fonts are installed on the client and will be made available to the X server on a glyph-by-glyph basis.

An X11 font server allows you to configure fonts for an entire organization from a single central location. The X.Org font directory is located at /etc/X11/fontpath.d/.

You need to install the fonts that you want to share on the X11 font server. Fonts are installed in the following directories:

  • /usr/share/fonts/Type1/ (Type 1)
  • /usr/share/fonts/truetype/ (TrueType)

Run the mkfontscale and mkfontdir commands to create a font description file and index the font, respectively. Then, open port 7100 in the X server host’s firewall.

Tell the X11 font service (xfs) that the fonts should be made available to remote X server clients by editing the /etc/X11/fs/config file. In /etc/X11/fs/config, comment out the no-listen = tcp line and verify that the appropriate font path is listed under catalog =.

Start the xfs daemon and configure it to start each time the system boots:

# systemctl enable --now xfs

To configure the remote X11 clients to consume the fonts provided by the X11 font server, add a new FontPath directive to the Files section of the X server's /etc/X11/xorg.conf file that points to the X11 font server. Typically, one FontPath entry per directory is added.

The order of the entries in the configuration file is important because it determines the X server's search order. The first matching font will always be used.

Instead of adding a font directory permanently to the configuration file, you can temporarily add it to the X server using the xset command. The following command temporarily adds a font directory (until the next restart of the X server):

# xset +fp '/usr/share/fonts/X11/truetype/'

This command undoes the change (i.e., it lets the X server forget about the new font directory again):

# xset -fp '/usr/share/fonts/X11/truetype/'

The xset q command lets you query the X server's current configuration and check that it knows about the correct font directories.

Apart from the fonts themselves, the font directory may contain the following files:

fonts.alias
File that lets you set up alias names for individual fonts.
fonts.dir
Contains a list of all of the fonts contained in the directory, including the filename, manufacturer, font name, font weight, slant, width, style, pixel and point sizes, x resolution, y resolution, font encoding, and various other data. A one-line entry for a font could look like this:
luBIS12-ISO8859-4.pcf.gz-b&h-lucida-bold-i-normal-sans-12-120-75-75-p-79-iso8859-4
The first line of the file gives the total number of fonts in the directory.
fonts.scale
File that is useful for directories containing scalable (i.e., vector-based, rather than bitmap-based) fonts and gives a list of the fonts in question.

The mkfontdir command is used to maintain the fonts.dir file. Assuming that you have added a font file to the /usr/local/share/X11/fonts/truetype/ directory, a call to # mkfontdir '/usr/local/share/X11/fonts/truetype/' will suffice to update the corresponding fonts.dir file.

If you add fonts to an existing font directory, you must issue the # xset fp rehash command within your running session for the X server to be able to find these fonts.

The font server, xfs, makes it possible to centrally manage fonts on a network. Without a font server, problems may arise if a client queries the X server for a list of available fonts. The X server will search the system for fonts, which can lead to considerable delays because, during that time, no X operations for graphics display will be executed.

xfs is a free-standing daemon. It offers its services on TCP port 7100 and is configured using the /etc/X11/fs/config or /etc/X11/xfs.conf files. After any changes to these files, the server must be informed of the changes by means of a SIGHUP signal (e.g., # pkill -SIGHUP xfs).

xfs accesses files that are installed as described for the X server, and can therefore also be used by the local X server. The font directories are entered into the configuration file by means of the catalogue parameter.

For example:

catalogue = /usr/share/fonts/X11/misc:unscaled,
            /usr/share/fonts/X11/75dpi:unscaled,
            /usr/share/fonts/X11/100dpi:unscaled

The individual paths must be separated by commas. Further options can be found in the documentation by running man 1 xfs.

To connect an X server to the font server, you need to add an entry to the Files section of the /etc/X11/xorg.conf file:

FontPath "tcp/ex_hostname:ex_port_number"

If you want to prefer fonts from the font server, you should add the above entry in front of all the other FontPath sections.

X Server Access Control

There are two native methods to control access to the X server:

  1. xhost
  2. xauth

xhost offers host-based access control. Usually, the xhost command is not recommended, since any user on the remote host can have access to your X session.

With xauth, a random key or magic cookie is created and passed to the X server when the server is started (usually by the display manager or startx). The key is also stored in the ${HOME}/.Xauthority file of the current user, which other users cannot read.

The X server only accepts connections from clients that can present the correct magic cookie. Using the xauth program, magic cookies can also be transferred to other hosts or removed from them.

Xorg's -nolisten tcp option lets you make your X server completely inaccessible from the outside. This is a sensible setting and many GNU/Linux distributions today default to it.

A more secure method to start X clients on remote hosts consists of using the X-forwarding feature of SSH. Check out 6.3 X11 Forwarding in the Tectia SSH Client User Manual for more information.

Display Managers

On modern workstations, it is normal to start the graphical environment when the system is booted by means of a display manager. The common GNU/Linux distributions offer several display managers, and the system picks one to start according to a distribution-specific selection mechanism.

One important function of a display manager is letting users log into the system in a graphical environment. Display managers delegate this task to greeters. There are various greeters that are usually written to blend in with different desktop environments. The greeters control the appearance of the login screen.

LightDM (LDM)

LightDM (LDM) is a popular display manager that is largely independent from specific desktop environments. It is relatively parsimonious with the system's resources, but can do all that is required from a display manager and can be installed on all major GNU/Linux distributions.

The configuration of LDM is contained in files whose names end in .conf within the /usr/share/lightdm/lightdm.conf.d/ and /etc/lightdm/lightdm.conf.d/ directories, as well as the /etc/lightdm/lightdm.conf file.

The configuration files are read in this order:

  1. /usr/share/lightdm/lightdm.conf.d/
  2. /etc/lightdm/lightdm.conf.d/
  3. /etc/lightdm/lightdm.conf

Ideally, if you need to make any changes, you should do so by placing files in /etc/lightdm/lightdm.conf.d/.

The configuration files are composed of sections that have titles within square brackets and contain key-value pairs. For example, you could change the X server layout by creating a file called /etc/lightdm/lightdm.conf.d/99local.conf containing the lines:

[Seat:*]
xserver-layout=presentation

The most important sections of the LightDM configuration include:

[LightDM]
Configuration for LightDM as a whole. This includes parameters like the user identity used for executing greeters, the directories for log files, runtime data, session information, and similar settings.
If you want to control more than one seat (i.e., combination of graphics card, monitor(s), keyboard, and mouse that is being controlled by a single X server), you must list the desired seats within this section. For example:
[LightDM]
seats = Seat:0, Seat:1, Seat:2
[Seat:*]
Configuration for a single seat.
This lets you specify whether the seat is locally connected or remote (X terminal), how the session should be constructed, and whether a user is automatically logged in. All of these settings apply to all seats connected to the computer, unless they are specifically overwritten.
The following example hides the clickable list of users in the greeter and allows the textual entry of user names. This can be useful for security purposes or because you have too many users and the resulting list would be unwieldy:
[Seat:*]
greeter-hide-users=true
greeter-show-manual-login=true

This example instructs the greeter to wait 10 seconds for user interaction before automatically logging in the user amnesia:

[Seat:*]
autologin-user=amnesia
autologin-user-timeout=10

The following code establishes mysession as the session name. This presupposes the existence of a file called /usr/share/xsessions/mysession.desktop describing the desired session:

[Seat:*]
user-session=mysession

Roughly, this could look like the following, where /usr/local/bin/startmysession would usually be a shell script that established the session:

[Desktop Entry]
Name=My Session
Comment=My very own graphical session
Exec=/usr/local/bin/startmysession
Type=Application
[Seat:0]
Configurations for individual seats that differ from the basic settings in [Seat:*].
[VNCServer]
Lets you configure an X server that is accessible via Virtual Network Computing (VNC) (the program is called Xvnc). This enables remote access from computers that do not support X11. There are VNC clients for many different operating systems.
[XDMCPServer]
Remote seats (X terminals) use X Display Manager Control Protocol (XDMCP) to contact the display manager. This section includes settings for XDMCP, included by default.
[XDMCPServer]
enabled = false

If LDM supports a greeter, it will have a configuration file for the greeter in /etc/lightdm/.

You can set up a background image with the standard greeter (preferably in the Scalable Vector Graphics (SVG) format). You will need to ensure that the /etc/lightdm/lightdm-gtk-greeter file contains something like:

[greeter]
background=/usr/local/share/images/lightdm/my_greeter_bg.svg

X Display Manager (XDM)

The X Display Manager (XDM) is the default display manager of the X11 system. It is plain and offers a simple graphical login window. It is configured using files in the /etc/X11/xdm/ directory, which includes:

Xresources
Customize the login interface presented to the user by the display manager after the system has booted. Lets you set up the greeting message (xlogin*greeting), the font used for the greeting (xlogin*login.greetFont), and the logo displayed by XDM (xlogin*logoFileName).
Xservers
Determine which X servers will be started for which displays. Changes the default color depth for the display manager.
Xsession
Plays a similar role for XDM as ${HOME}/.xinitrc does for startx and xinit, as far as initialization of a user session is concerned. There is a user-specific analogue, ${HOME}/.xsession, as well.
Xsetup
A shell script that will be executed when XDM is started. Among other things, this lets you start a program that puts a background image on the login screen.

Simple Desktop Display Manager (SDDM)

The Simple Desktop Display Manager (SDDM) derives from the KDE project. It was written from scratch in C++11 and supports theming via QML.

GNOME Display Manager (GDM)

The GNOME Display Manager (GDM) is part of the GNOME desktop environment. It supports both X11 and Wayland, and allows users to choose their session type on a per-login basis.

It is configured using the /etc/gdm3/daemon.conf file.

Display Manager Configuration Directories

Display Manager Configuration Directories
Display Manager Non-Host Specific Host-Specific
LDM /usr/share/lightdm/ /etc/lightdm/
XDM /usr/share/xdm/ /etc/X11/xdm/
SSDM /usr/lib/sddm/sddm.conf.d/ /etc/sddm.conf.d/
GDM /var/lib/gdm3/ /etc/gdm3/

Display Manager Commands

echo "${XDG_SESSION_TYPE}"
Display the name of your system's display server protocol (e.g., x11, wayland).
echo "${XDG_CURRENT_DESKTOP}"
Display the name of your system's desktop environment (e.g., GNOME).
xdpyinfo
Display information about an X server.
This command describes the graphical possibilities offered by an X server. A visual describes how to put pixels of specific colors onto the screen, where TrueColor is the goal.
xwininfo
Display information about X11 windows.
After starting this command, it prompts you to select the desired window using the mouse/touchpad. Use the plus sign (+) to select which window that you want information on.
The output will give you the coordinates of the window on the screen, the visual in use, and similar data. The backing store state and the save under state determine what happens to window content that is obscured by other windows (typically pop-up menus). They will not be stored, but redrawn as required. The map state specifies whether the window is actually visible on screen.
You can find the window information without a click/tap if you know the window ID of the window's name. The window name is on the same line as the window ID.
xwininfo supports various options that control the type and extent of the data being output.
# systemctl start ex_display_manager
Start a display manager.
# systemctl stop ex_display_manager
Stop a display manager.
# xvidtune
Present various buttons and sliders that can be used to interactively adjust existing video modes. Also, print the settings in a format suitable for inclusion in the /etc/X11/xorg.conf file.
xhost
Display a message indicating whether or not X access control is currently enabled, followed by the list of those allowed to connect.
xhost +
Access is granted to everyone, even if they are not on the X access control list (i.e., X access control is turned off).
xhost -
Access is restricted to only those on the X access control list (i.e., X access control is turned on).
xhost +ex_host...
Add named host to X access control list. The + is optional.
xhost -ex_host...
Remove named host from X access control list.

Wayland

The current trend in GNU/Linux graphics is based on the observation that the X server tends to do little of a useful nature beyond providing help, i.e., the compositor and the clients are doing the real work. The future infrastructure, Wayland, gets rid of the X server altogether. Wayland implements a compositor that can directly talk to the graphics chip, which makes the X server superfluous.

The prerequisite is that clients generate graphics output as 3D operations (in OpenGL), rather than X11 operations. This is reasonable to enforce by adapting the toolkits (i.e., the programming environments for X11 clients). Popular toolkits already contain Wayland support of a more or less maturing nature.

Accessibility

GNU/Linux distributions contain myriad accessibility technologies, including:

AccessX
Allows you to configure a wide variety of keyboard accessibility settings that enable physically impaired users to use a traditional keyboard.
BounceKeys, DelayKeys
Inserts a slight delay between keystrokes to prevent the keyboard from sending unintentional keystrokes.
MouseKeys
Allows the mouse to be controlled using the numeric key pad on the keyboard.
RepeatKeys
Allows you to specify whether held-down keys should be repeated or just reported once.
SlowKeys
Lets the system ignore unwanted key presses that arise when you press other keys on the way to the key that you really want.
StickyKeys
Arranges for modifier keys like Shift and Control keys not to have to be held down while you are pressing another key. A press (and subsequent release) of the modifier key is enough for the next key to be evaluated, as if the modifier key was still held down.
ToggleKeys
Sounds an audible alert if either the CAPS LOCK or the NUM LOCK key is on.

GNU/Linux distributions provide the option of using an on-screen keyboard.

Assistive Technologies also provide mouse accessibility options for physically impaired users. The following options can be configured:

Dwell click
Sends a mouse click whenever the mouse pointer stops moving for a specified amount of time.
Mouse gestures
The equivalent of keyboard shortcuts. Allows you to complete a certain task when you move the mouse in a specific way.
Simulated secondary click
Allows you to send a double-click by holding down the primary mouse button for a specified period of time.

With X on GNU/Linux, these tools are provided by the XKEYBOARD extension that, by default, is part of the X server. You can activate it by using the xkbset utility, which controls keyboard setup options for X. The graphical desktop environments also offer user interfaces like the KDE Control Center.

For GNOME, there is a screen keyboard called GOK, which allows users to type by means of a mouse, a joystick, or even a single key. This is a tool for people who cannot handle a keyboard, but can use the mouse.

In many cases, the mouse can be replaced by the keyboard. All features of the graphical environment should also be available via the keyboard. People that cannot use the mouse (e.g., due to repetitive strain injury (RSI)), may prefer to use a stationary track ball. For people with motor difficulties, it may also help to increase the delay for double clicks.

GNU/Linux has the considerable advantage that the screen display can be finely controlled. Both KDE Plasma and GNOME allow you to change the size of the display fonts. Visually impaired people greatly benefit from a generously oversized text representation. A high-contrast color scheme also helps to make the desktop easier to view.

Another common tool is a screen magnifier, which displays a greatly magnified copy of the area around the mouse cursor. The KMagnifier program of KDE Plasma and the GNOME equivalent, GNOME Magnifier, both offer this useful feature.

For blind people, GNU/Linux supports various Braille displays, as well as voice output. A Braille display can show a line of text using Braille dot representation, which the blind can feel using their fingertips. However, Braille devices are fairly expensive and mechanically intricate.

BrlTTY is a program that runs on the GNU/Linux console and controls a Braille display. Orca is the same for GNOME. Then, there is Emacspeak, which is essentially a screen reader for GNU Emacs that reads screen contents aloud. Since many other programs can be launched inside of Emacs, this is nearly as good as a graphical desktop.

Several types of Braille displays and embossers are supported. The GNU/Linux system must be running the brltty daemon to use them.

You can configure screen readers to help visually impaired users. The previously mentioned Orca application is probably the most commonly used GNU/Linux screen reader. Orca also provides a screen magnifier, which allows visually impaired users to magnify areas of the screen as if they were using a real magnifying glass.

Documentation

You can find more information on the commands discussed above by examining the Linux User's Manual, either at the command line or online.

Enjoyed this post?

Subscribe to the feed for the latest updates.