2021 Call for Code Awards: Live from New York, with SNL’s Colin Jost! Learn more

Learn Linux 101: Install and configure X11


In this tutorial, learn to install and configure X11 for your Linux system. Learn to:

  • Understand the X11 architecture.
  • Understand the basics of the X Window configuration file.
  • Overwrite specific aspects of Xorg configuration, such as keyboard layout.
  • Understand the components of desktop environments, such as display managers and window managers.
  • Manage access to the X server and display applications on remote X servers.
  • Understand Wayland.

What is X11?

The X Window System (also known as X11, or simply X) is a client/server windowing system for bitmap displays. It is implemented on most UNIX-like operating systems and has been ported to many other systems. The X server is the program or dedicated terminal that displays the windows and handles input devices such as keyboards, mice, and touchscreens. The clients are applications.

This tutorial helps you prepare for Objective 106.1 in Topic 106 of the Linux System Administrator (LPIC-1) exam 101. The objective has a weight of 2.


To get the most from the tutorials in this series, you need a basic knowledge of Linux and a working Linux system on which you can practice the commands that are covered in this tutorial. Sometimes, different versions of a program format output differently, so your results might not always look exactly like the listings and figures that are shown here. The examples in this tutorial come from Fedora 28, openSUSE Tumbleweed (20181204), and Ubuntu 18.04 LTS.

X, the big picture

X was originally developed at the Massachusetts Institute of Technology (MIT) in 1984. The client/server X protocol is Version 11 (X11) and has been so since 1987. The X.Org Foundation now leads the X project, with the current reference implementation, X.Org Server, available as free and open source software. It is under the MIT License and similar permissive licenses.

The X architecture provides a fairly primitive client/server framework for a graphical display, including drawing and moving windows on the display and interacting with input devices such as keyboards, mice, tablets or touchscreens. X is designed to be network transparent, so that an X server can display windows from local or networked application sources. In the days of very expensive computers that were shared among many users, X terminals provided a low cost way for many users to share the resources of a single computer. The terminal implemented the X protocol and the computer handled the rest of the work needed.

Individual application windows occupy some or all of a display screen and a user usually has multiple such windows open at a time. X does not specify how this management task should be accomplished, so a manager program usually provides this. Examples of such managers include the GNOME or KDM display managers or the Enlightenment window manager. These interfaces typically provide features such as frames, title bars and standard menus, and usually provide a means for a user to launch programs. Thus different systems may look and feel very different even when they all use X. Later in this tutorial, I will discuss more about window managers and display managers.

Merging and displaying the required parts of several application windows is called compositing. This is part of the window manager. So X handles the application requests, and passes them to the manager’s compositor for assembly of the window to be shown to the user. The final image is then passed back to the X server for display.

Figure 1 shows an example of a typical modern Linux desktop (from openSUSE Tumbleweed). Three windows are open and the user is using the system menus to launch another application.

Figure 1. Example of an openSUSE desktop
Example of an openSUSE desktop

The X Window configuration file

In the early days of X, configuring a display meant having extensive knowledge of the display’s capabilities and the ability to express information about not only resolution, but also horizontal and vertical sync values, color depth, and so on. Since the advent of the Video Electronics Standards Association (VESA) and the Display Data Channel (DDC) protocols that allow a display to communicate these capabilities to a graphics card and thus to a computer, configuration has become much more automatic. This is fortunate as we now expect to be able to take our notebook anywhere and just plug in an available external monitor or projector.

Configuring your mouse, trackball, or keyboard has also become more automatic. Generally, you just plug in the device, often through a USB connection and it works.

However, as with most things in Linux, there is an underlying configuration mechanism that you can use. In fact, the Xorg implementation of X obtains configuration information from several sources. The main configuration file is xorg.conf, along with files included from the xorg.conf.d directory. These are usually located in /etc/X11. Additional configuration can come from command-line options, environment variables, auto-detection, and fallback defaults.

The xorg.conf configuration file and the files in the xorg.conf.d directory are organized into sections which may be specified in any order. The general section format is shown in Listing 1.

Listing 1. Section layout in xorg.conf

    Section  "SectionName"

If a section is omitted, other sources or defaults will be used.

You can include the following sections:

  • Files – File pathnames
  • ServerFlags – Server flags
  • Module – Dynamic module loading
  • Extensions – Extension enabling
  • InputDevice – Input device description
  • InputClass – Input class description
  • OutputClass – Output class description
  • Device – Graphics device description
  • VideoAdaptor – Xv video adaptor description
  • Monitor – Monitor description
  • Modes – Video modes descriptions
  • Screen – Screen configuration
  • ServerLayout – Overall layout
  • DRI – DRI-specific configuration
  • Vendor – Vendor-specific configuration

Read the man or info pages for xorg.conf to find out more about the various sections of the files. Man pages for Xserver and Xorg provide additional information.

With much of the configuration now determined dynamically, it is quite common for many distributions to install X without creating either an xorg.conf file or any files in /etc/X11/xorg.conf.

If you want or need to create a starting configuration file for X, use the Xorg command with the -configure option. The Xorg command is actually a symbolic link from the X command usually located in /usr/bin. You need to run the Xorg command as root and ensure that no X server is running. One way to do this is to edit your GRUB2 stanza to boot into multi-user mode without X. Traditionally, this is runlevel 3. Simply edit the boot menu entry that you wish to boot and add a 3to the end of the `linux boot/vmlinuz…’ line as illustrated in Figure 2.

Figure 2. Booting into multi-user mode without X
Booting into multi-user mode without X

If you are using systemd, you can use systemd.unit=multi-user.target instead of 3.

Xorg -configure loads available device drivers and probes for hardware. It works on many systems, but has problems on some systems according to the man page. The Fedora documentation recommends using the :1 display instead of the default :0 display, so you can try Xorg :1 -configure if plain Xorg -configure does not work.

A sample file generated using this method on my openSUSE Tumbleweed system is shown in Listing 2.

Listing 2. Example xorg.conf

Section "ServerLayout"
        Identifier     "X.org Configured"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"

Section "Files"
        ModulePath   "/usr/lib64/xorg/modules"
        FontPath     "/usr/share/fonts/misc:unscaled"
        FontPath     "/usr/share/fonts/Type1/"
        FontPath     "/usr/share/fonts/100dpi:unscaled"
        FontPath     "/usr/share/fonts/75dpi:unscaled"
        FontPath     "/usr/share/fonts/ghostscript/"
        FontPath     "/usr/share/fonts/cyrillic:unscaled"
        FontPath     "/usr/share/fonts/misc/sgi:unscaled"
        FontPath     "/usr/share/fonts/truetype/"
        FontPath      "built-ins"

Section "Module"
        Load   "glx"
        Load   "vnc"

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5 6 7"

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Monitor Model"

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
        ### <percent>: "<f>%"
        ### [arg]: arg optional
        #Option     "SWcursor"             # [<bool>]
        #Option     "HWcursor"             # [<bool>]
        #Option     "NoAccel"              # [<bool>]
        #Option     "ShadowFB"             # [<bool>]
        #Option     "VideoKey"             # <i>
        #Option     "WrappedFB"            # [<bool>]
        #Option     "GLXVBlank"            # [<bool>]
        #Option     "ZaphodHeads"          # <str>
        #Option     "PageFlip"             # [<bool>]
        #Option     "SwapLimit"            # <i>
        #Option     "AsyncUTSDFS"          # [<bool>]
        #Option     "AccelMethod"          # <str>
        #Option     "DRI"                  # <i>
        Identifier  "Card0"
        Driver      "nouveau"
        BusID       "PCI:1:0:0"

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        SubSection "Display"
                Viewport   0 0
                Depth     1
        SubSection "Display"
                Viewport   0 0
                Depth     4
        SubSection "Display"
                Viewport   0 0
                Depth     8
        SubSection "Display"
                Viewport   0 0
                Depth     15
        SubSection "Display"
                Viewport   0 0
                Depth     16
        SubSection "Display"
                Viewport   0 0
                Depth     24

Note that there are two InputDevice sections, one for keyboard and one for mouse. The Monitor section in this example contains three Display subsections. You can find information about the display devices that were found by your system in /sys/class/drm as shown in Listing 3.

Listing 3. Detected displays from /sys/class/drm

attic4-stw:~ # ls /sys/class/drm
card0          card0-HDMI-A-1  renderD128  version
card0-DVI-I-1  card0-VGA-1     ttm
attic4-stw:~ # for n in /sys/class/drm/card0-*; do echo $n $(cat $n/status);done
/sys/class/drm/card0-DVI-I-1 disconnected
/sys/class/drm/card0-HDMI-A-1 connected
/sys/class/drm/card0-VGA-1 disconnected

This system has a video card that has High-Definition Multimedia Interface (HDMI), Digital Video Interactive (DVI), and Video Graphics Array (VGA) output interfaces. Hence the three subsections. There is a display connected to the HDMI output.

Assuming your display supports DDC,as most modern displays do, you can use the xrandr command to query its capabilities. Listing 4 shows the drm information for a notebook with a connected display and the corresponding output from xrandr.

Listing 4. Using xrandr to determine display capabilities

[root@localhost ~]# ls /sys/class/drm
card0  card0-eDP-1  card0-HDMI-A-1  renderD128  version
[root@localhost ~]# for n in /sys/class/drm/card0-*; do  echo $n $(cat $n/status);done
/sys/class/drm/card0-eDP-1 connected
/sys/class/drm/card0-HDMI-A-1 connected
[root@localhost ~]# xrandr -q
Screen 0: minimum 320 x 200, current 3286 x 1080, maximum 8192 x 8192
eDP-1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm
   1366x768      60.02*+
   1280x720      60.00    59.99    59.86    59.74  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   1024x576      59.95    59.96    59.90    59.82  
   960x600       59.93    60.00  
   960x540       59.96    59.99    59.63    59.82  
   800x600       60.00    60.32    56.25  
   840x525       60.01    59.88  
   864x486       59.92    59.57  
   700x525       59.98  
   800x450       59.95    59.82  
   640x512       60.02  
   700x450       59.96    59.88  
   640x480       60.00    59.94  
   720x405       59.51    58.99  
   684x384       59.88    59.85  
   640x400       59.88    59.98  
   640x360       59.86    59.83    59.84    59.32  
   512x384       60.00  
   512x288       60.00    59.92  
   480x270       59.63    59.82  
   400x300       60.32    56.34  
   432x243       59.92    59.57  
   320x240       60.05  
   360x202       59.51    59.13  
   320x180       59.84    59.32  
HDMI-1 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 509mm x 286mm
   1920x1080     60.00*+
   1600x1200     60.00  
   1680x1050     59.88  
   1400x1050     59.95  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   640x480       75.00    72.81    66.67    59.94  
   720x400       70.08

Changing the configuration

If you want to change your keyboard layout, say to allow switching between US and UK keyboards, you might edit the keyboard section of your xorg.conf file. Listing 5 shows an updated 00-keyboard.conf from /etc/X11/xorg.conf.d on my openSUSE Tumbleweed system.

The XkbVariant option defines which variants of the two layouts should be used. In case of the us layout its default variant is used. In case of the sk layout its qwerty variant is used. The XkbOptions option indicates that users can toggle between layouts using the CapsLock key.

Listing 5. Updating the keyboard configuration

# Written by systemd-localed(8), read by systemd-localed and Xorg. It's
# probably wise not to edit this file manually. Use localectl(1) to
# instruct systemd-localed to update it.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us,uk"
        Option "XkbModel" "pc104"
        Option "XkbVariant" ",qwerty"
        Option "XkbOptions" "grp:caps_toggle"

As noted in the comments at the top of the file, keyboard layouts are managed by the localectld daemon on systems that use systemd. Rather than directly editing xorg.conf in this way to update keyboard settings, you should probably use the localectl command. However, localectl status shows that these changes were picked up when the system was restarted as shown in Listing 6.

Listing 6. Showing keyboard status using localectl

ian@attic4-stw:~> localectl status
   System Locale: LC_CTYPE=en_US.UTF-8
       VC Keymap: us
      X11 Layout: us,uk
       X11 Model: pc104
     X11 Variant: ,qwerty
     X11 Options: grp:caps_toggle

Window managers and display managers

What may not be evident from the discussion so far is that X provides an ability to display stuff on a display screen and accept input for devices such as mice, keyboards, tablets or touch screens, but it does not provide much of a way for a user to actually use all these capabilities. Enter window managers and display managers. Window managers provide basic support that allows you to use multiple application windows on a display, launch new windows, and switch between windows. If the individual window provides a frame or a menu, good!. If not, then too bad! Display managers generally add menu and frames and provide other capabilities that make it easier to launch applications. They also provide a consistent theme for your desktop. Display mangers usually provide a “greeter” top help you log in or choose between different window or display managers. Display managers often have some underlying window manager.

Display managers fall into three general categories.

  1. Tiling window managers divide the screen into tiles and write each tile separately form others. Performance is generally good.
  2. Stacking window mangers stack individual windows on the screen in a list known as a Z-order. When a new window is given focus it is placed on top of the Z-order and all lower windows are redrawn. This can be slow, particularly for minor changes, but several optimizations have been developed.
  3. Compositing window managers are usually stacking window managers that keep a buffer for each window and then combine them into a single buffer for display without needing to redraw each individual window and then overwrite it with the next higher one in the Z-order. This also allows effects such as transparency.

Figure 3 shows an example of the I3 tiling window manager. You start with an empty desktop and then create a window such as a terminal window. This occupies the full screen. You can then open another window which splits the original tile into two. If you then open another, the screen is split into three tiles. You can elect to create new tiles horizontally or vertically. In this example, I chose to split the original middle tile containing the sudoku game vertically, to create another small terminal window. Then I split that horizontally to add an xlcock window.

Figure 3. The I3 tiling window manager
The I3 tiling window manager

You can usually move windows between virtual desktops which helps a lot if you have multiple large windows open.

You can open the list of available applications as a menu across the top of the screen and select applications by slow horizontal scrolling or more rapidly by typing part or all of a name such as ‘xclock’.

In contrast to tiling window managers, stacking window managers enable you have windows of any size supported by your display, including windows that may overlap the edge of the display. Figure 4 is an example of the Openbox stacking window manager showing four overlapping windows and the menu that enables you open new applications.

Figure 4. The Openbox stacking window manager
The Openbox stacking window manager

Basic stacking window managers work on the principle of redrawing all the windows on your display when the window with focus changes or is moved, closed, or resized. This may result in multiple rewrites of various areas of the screen as the whole Z-order is processed. Algorithms can be used to minimize the amount of unnecessary rewrite.

An improvement on the basic stacking idea is a compositing window manager. Such a window manager keeps a buffer of the contents of each window and merges or composits these into a single window. Only the updated parts then need to be written to the display card buffer. Compiz is one example of a compositing window manager, while desktop environments such as KDE and GNOME also use compositing window managers.

A desktop environment generally provides a full-featured user experience, including things such as a graphical login greeter, graphical system menus, a tray to display widgets such as time of day, open application icons, and so on. A suite of integrated applications usually provides a consistent experience for a user. Most window managers are much more lightweight than a full desktop environment.

Figure 5 illustrates the concept of transparency in a compositing window manager or desktop environment. Hold down the left mouse button (button 1) on the title bar of the terminal window when preparing to move it. The display changes to show what windows are below that particular area. This might help you move one window from being on top of another one when you would like both to be visible.

Figure 5. Transparency with KDE Plasma desktop
Transparency with KDE Plasma desktop

Figure 6 illustrates GNOME 3.28 on Fedora. Clicking the Activities button at the upper-left side of this screen opens up an iconized list of favorites on the left side of the screen and shows a set of running applications as small windows. You can click a favorite, click a small window, or use the search box at the top of the screen to search for a program. In this particular example, I have clicked the day and time in the top bar to open a widget that shows some messages, such as available updates or last command completed, as well as additional date and time information. The icons at the upper-right side allow access to functions such as speaker volume, network settings, accessibility options and shutdown, logout or reboot options.

Figure 6. Fedora GNOME activities and widgets
Fedora GNOME activities and widgets

I mentioned that desktop environments frequently contain integrated applications to help you manage various aspects of the desktop or the system. Figure 7 shows the Fedora GNOME 3.28 settings dialog open at the display settings. This example is from a notebook with an external Viewsonic monitor. Common choices in this case are to join the two screens as a single display or to mirror the contents of one screen onto the other. In this case, we choose to join the two displays with the built-in display logically to the right of the external monitor.

Figure 7. Fedora GNOME Screen Settings dialog
Fedora GNOME Screen Settings dialog

As you can change the screen resolution in the xorg.conf file, you can also tell the compositor to scale the window to either 100% or 200%. Available scaling may depend on the monitor size as well as the particular desktop you are using. I also have a UHD (4K) monitor and eyes that cannot read the very small native text resolution. So on that monitor, I frequently use a scaling factor of 200%.

Note that changes made using the GNOME settings do not update xorg.conf. Instead these settings are saved in the .config/monitors.xml file in your home directory. GNOME also maintains other display and keyboard settings in the dconf database which you can also find below your home directory. By having these settings in your home directory, they apply only to you. Other users may have different settings.

If you have multiple desktop environments or window managers installed you may be wondering how you choose between them. You can boot into the multi-user mode as described earlier in this tutorial and then run a command such as startx to start X with the appropriate manager. If you have a desktop environment such as GNOME providing a greeter,you will probably have a settings choice on the greeter screen. Figure 8 shows the choices installed on my Fedora 28 system.

Figure 8. Fedora GNOME 3 greeter with WM selection
Fedora GNOME 3 greeter with WM selection

Manage access to the X server and display applications remotely

So far, you have seen examples of X running on a desktop computer with one, or perhaps two monitors. An X server treats a single display as a collection of monitors that share a common set of input devices.

So the notebook shown in Figure 7 has one display, even though it has the built-in monitor and an external monitor. In this example, the two monitors work as if joined together. This makes a single logical screen that allows windows to be moved between monitors, or even split across them. Multi-user systems usually have multiple displays so you need a way to describe them.

X uses a three part name for displays of the form hostname:displaynumber.screennumber where hostname is the computer host name, displaynumber is a number starting at 0 that describes the particular display, and screennumber applies if two or more monitors are treated as separate screens rather than as a single logical screen. Both hostname and screennumber can be omitted, so the most common display notation you will see is :0. You can see your current setting in the DISPLAY environment variable as shown in Listing 7.

Listing 7. The DISPLAY environment variable

ian@attic5-u18:~$ echo $DISPLAY

You might think that setting the DISPLAY environment variable would allow any user to write output on your screen, but X has some access control limitations. I will show you three ways to connect to an X server.

  1. Use ssh with X forwarding
  2. Use Xauthority and xauth
  3. use host or user control with xhost

The most secure way to use X on another display is to use X forwarding (sometimes called tunneling). This must be enabled on the SSH server that you connect to with the line X11Forwarding yes in the configuration file, /etc/ssh/sshd_config. You also need to enable it on the client by specifying the option -X (that’s capital X) in your ssh command. Listing 8 compares what happens if I use su - jane to switch to user jane on my system and then use ssh -X jane@localhost. In both cases, I attempt to run the xclock command to display a small clock on my screen.

Listing 8. X forwarding

ian@attic5-u18:~$ # First use su - jane
ian@attic5-u18:~$ su - jane
jane@attic5-u18:~$ echo $DISPLAY
jane@attic5-u18:~$ xclock&
[1] 2437
jane@attic5-u18:~$ No protocol specified
Error: Can't open display: :0

[1]+  Exit 1                  xclock
jane@attic5-u18:~$ logout
ian@attic5-u18:~$ # Now try ssh -X
ian@attic5-u18:~$ ssh -X jane@localhost
jane@localhost's password:
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-42-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

 * Canonical Livepatch is enabled.
   - All available patches applied.

0 packages can be updated.
0 updates are security updates.

Last login: Wed Dec 12 11:29:41 2018 from
jane@attic5-u18:~$ echo $DISPLAY
jane@attic5-u18:~$ xclock&
[1] 2543
jane@attic5-u18:~$ logout
Connection to localhost closed.

Notice that after the ssh login, the DISPLAY variable is set to localhost:10.0. The sshd server is effectively creating an X server for you on the target system. You don’t want this to interfere with any real X servers on the system. So the configuration file, /etc/ssh/sshd_config, contains a line X11DisplayOffset 10 to specify the starting offset (from 0) for X servers over ssh. The default is 10, which is usually plenty for a single user workstation but might need to be increased in a multi-user system. A second ssh connection to the server would be assigned display 11 and so on.

The second method to enable others to connect to an X server is the Xauthority method. The Xauthority file contains authorization information used when you connect to an X server. The XAUTHORITY environment variable specifies the name of the file currently in use, either a system generated file such as /run/user/1000/gdm/Xauthority on my Ubuntu 18 system, or your own .Xauthority file.

Use the xauth command to list, extract, or merge in new authorities. use the -f option to specify an Xauthority file other than the one in your XAUTHORITY environment variable. You can specify xauth commands on the command line, or start it and use the commands from within the program. Listing 9 shows some examples and extracts my authorization for display :0 to a file named auth-ian.

Listing 9. Extracting authority information using xauth

ian@attic5-u18:~$ echo $XAUTHORITY
ian@attic5-u18:~$ xauth list
attic5-u18/unix:  MIT-MAGIC-COOKIE-1  ed4e7b779c5f7509da089ec397b9f467
#ffff#6174746963352d753138#:  MIT-MAGIC-COOKIE-1  ed4e7b779c5f7509da089ec397b9f467
ian@attic5-u18:~$ xauth
Using authority file /run/user/1000/gdm/Xauthority
xauth> extract auth-ian :0
2 entries written to "auth-ian"
xauth> quit
ian@attic5-u18:~$ xauth -f auth-ian list
attic5-u18/unix:  MIT-MAGIC-COOKIE-1  ed4e7b779c5f7509da089ec397b9f467
#ffff#6174746963352d753138#:  MIT-MAGIC-COOKIE-1  ed4e7b779c5f7509da089ec397b9f467
ian@attic5-u18:~$ ls -l auth-ian
-rw------- 1 ian ian 108 Dec 12 12:39 auth-ian

Notice the permissions on the auth-ian file. Connections to your display can be made by anyone who has this information. Be warned! If you want another user to access your display, you can transfer the extracted authority information to the user using a secure method such as Secure Copy Protocol (SCP) or passing the file on physical media. Assuming I have transferred this file to user jane by some secure means, Listing 10 shows how to create a .Xauthority file (if one does not exist), merge in the credentials, and set the XAUTHORITY environment variable. User jane can then display applications on my display.

Listing 10. Merging authority information using xauth

jane@attic5-u18:~$ export XAUTHORITY=.Xauthority
jane@attic5-u18:~$ xauth merge auth-ian
xauth:  file .Xauthority does not exist
jane@attic5-u18:~$ touch .Xauthority
jane@attic5-u18:~$ chmod 600 .Xauthority
jane@attic5-u18:~$ xauth merge auth-ian
jane@attic5-u18:~$ xauth list
#ffff#6174746963352d753138#:  MIT-MAGIC-COOKIE-1  ed4e7b779c5f7509da089ec397b9f467
#ffff#6174746963352d753138#:  MIT-MAGIC-COOKIE-1  ed4e7b779c5f7509da089ec397b9f467
jjane@attic5-u18:~$ echo $DISPLAY
ane@attic5-u18:~$ xclock&
[1] 4620

Note that on my local system user jane still uses the :0 display.

Before the advent of ssh X tunneling, it was not uncommon to open windows on remote servers. This can be done using xauth to get the key of the remote system. You also need to open the X11 port on the remote server (usually TCP port 6000). If you are running a display manager on the remote system you will also find other configuration requirements, such as enabling various options in your display manager configuration. If you do this, the X credentials (magic cookie) are passed in the clear, so there is some slight security risk on anything but a very local network.

The final and least secure method of allowing others to access your display is to use the xhost command. On a workstation, you may well use this to allow you to open graphical programs while running as another user. The xhost command with no options displays the current access control list. Use the + option with a name to allow additional systems or users. Listing 11 shows how to add user john on my local system to the access control list and then shows user john opening the graphical xclock program.

Listing 11. Using xhost to enable a single local user

ian@attic5-u18:~$ xhost
access control enabled, only authorized clients can connect
ian@attic5-u18:~$ xhost +si:localuser:john
localuser:john being added to access control list
ian@attic5-u18:~$ su - john
john@attic5-u18:~$ xclock &
[1] 9184
[1]+  Done                    xclock
john@attic5-u18:~$ logout

You enable all local non-networked users using xhost +local: as shown in Listing 12. Note the colon (:) at the end of local.

Listing 12. Using xhost to enable all local non-networked users

ian@attic5-u18:~$ xhost +local:
non-network local connections being added to access control list
ian@attic5-u18:~$ xhost
access control enabled, only authorized clients can connect
ian@attic5-u18:~$ su - pat
pat@attic5-u18:~$ xclock&
[1] 9203

Use - instead of + to remove entries that you have enabled. See the xhost man or info pages for additional options.

For security you should use SSH tunneling or possibly another solution such as Virtual Network Computing (VNC) rather than xauth or xhost. VNC is outside the scope of this tutorial but provides better performance than SSH tunneling.

When things go wrong

With so many possible sources of X configuration information you need to know where to look for log information. Errors related to your individual X session may be located in the .xsession-errors or possibly .xsession-errors-:0 in your home directory. The :0 suffix is for errors on display :0.

The main X log is located in /var/log. The name is usually /var/log/Xorg.0.log, where 0 is your display number. The number will be different if you are not using display :0.

Wayland, a new compositing window manager

Recently, a new display server and compositing protocol called Wayland has been developed. In this model applications, create their window contents themselves in an off-screen buffer. The compositor and server are integrated. The intent of Wayland is to provide a simpler and more efficient solution than X. Wayland mostly reuses existing drivers and infrastructure which makes the project possible.

In contrast to X, Wayland does not have a network transparent design. Other solutions such as VNC may be used if remote window display is needed.

Weston is a reference compositor implementing Wayland. GNOME, KDE, Enlightenment, and several other window managers now support Wayland. Toolkits such as Qt 5 and GTK+ also support Wayland. At the time of writing (December 2018) both Fedora and Ubuntu ship with Wayland as the default display server.

The Xorg server now includes XWayland which allows existing X applications to run with a Wayland compositor.

Most current implementations still have a choice of running either X or Wayland for each session. See Figure 7 for an example of how the GMS greeter allows you to choose a session type. On Fedora the default is to run GNOME on Wayland.

You can also check at run time without having to log in. If you are running Wayland, the WAYLAND_DISPLAY environment variable will be set. On systems using systemd, you can use the loginctl command to determine your login session number and then use it again to determine your session type. Listing 13 shows these tools, first on a Fedora 28 system using Wayland and then on a Ubuntu 18 system running Xorg.

Listing 13. Determining whether you are using X or Wayland

[ian@attic4-f28 ~]$ echo $WAYLAND_DISPLAY
[ian@attic4-f28 ~]$ loginctl
   SESSION        UID USER             SEAT             TTY
         4       1000 ian              seat0            tty2
        c1         42 gdm              seat0            tty1

2 sessions listed.
[ian@attic4-f28 ~]$ loginctl show-session 4 -p Type

ian@attic5-u18:~$ echo $WAYLAND_DISPLAY

ian@attic5-u18:~$ loginctl
   SESSION        UID USER             SEAT             TTY
        c1        121 gdm              seat0            tty1
         2       1000 ian              seat0            tty2

2 sessions listed.
ian@attic5-u18:~$ loginctl show-session 2 -p Type

This completes your introduction to the X Window system.