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:
- X Window System (X11, X)
- Graphical system login
- 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:
xhost
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:
/usr/share/lightdm/lightdm.conf.d/
/etc/lightdm/lightdm.conf.d/
/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 useramnesia
:[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 forstartx
andxinit
, 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
Select to view Display Manager Configuration Directories
Display Manager | Non-Host Specific | Host-Specific |
---|---|---|
LDM | /usr/share/lightdm/ code> |
/etc/lightdm/ code> |
XDM | /usr/share/xdm/ code> |
/etc/X11/xdm/ code> |
SSDM | /usr/lib/sddm/sddm.conf.d/ code> |
/etc/sddm.conf.d/ code> |
GDM | /var/lib/gdm3/ code> |
/etc/gdm3/ code> |
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.