The X Window System is a graphical windowing system that was developed at MIT in 1984. X was developed as part of Project Athena, a cooperative effort between MIT, IBM, and Digital Equipment Corporation to develop a network of heterogeneous engineering terminals that could be used for teaching purposes. The current version, X11, was released in 1987 and is now up to X11 release 6, known as X11R6.
One reason X has had such staying power is that from the beginning it incorporated many of the windowing capabilities that we now take for granted. These capabilities include network transparency, graphical capability, the use of a mouse, and the ability to link together a heterogeneous network of workstations from different vendors.
In addition, X was intentionally designed to provide the low-level mechanism for managing the graphics display, but not to have any control over what is displayed. This means that X has never been locked into a single way of doing things; instead, it has the flexibility to be used in many different ways. Both the simplest window manager and the most complex desktop environment can, and do, use the X Window System to manage the display.
The responsibility and stewardship of X is currently in the hands of the X.Org Foundation; the X.Org implementation of the X Window System is included with most of the major Linux and free Unix distributions. Until 2004, the standard version of X was XFree86, developed by the XFree86 Project. New licensing restrictions imposed by XFree86 led to the switch to X.org.
The client/server model, as it is implemented by X, may seem backward at first glance. Generally, we think of servers as remote machines like file servers, news servers, or mail servers, with local clients accessing the servers. For X, however, it's the server that runs on the local machine, providing its services to the display based on requests from client programs that may be running locally or remotely. The server also manages the input devices (usually a keyboard and mouse), and it manages the display of colors and fonts on the screen, all based on requests from a client.
One of the most significant features of X is that it was specifically designed to work across a network. The client and the server communicate via the X Protocol, a network protocol that can run locally or across a network. Regardless of whether a client program is local or remote, it communicates with the server through the X Protocol.
Let's talk briefly about working with X, and then we'll take a look at some of the major pieces.
When you run the X Window System, the X server manages the display, based on requests from the window manager. The window manager is an application that is itself an X client, with responsibility for managing the appearance and placement of the windows on the screen.
X itself has no role in determining the appearance of the screen, or what users are allowed to do with windows. That is the job of the window manager. For example, some window managers allow you to double-click in a window's title bar and roll up the window into the title bar like rolling up a window shade (this is referred to as shading). Other window managers don't have that feature. X doesn't care; it's a window manager concern. The X server's job is to provide the low-level support so the window manager and other applications can shade or not, as they choose.
Similarly, the window manager takes care of the appearance and placement of the windows; it doesn't determine what goes on inside. The window might be a terminal window (called an xterm) where the user runs standard Unix commands, or it might be running an X client application like the xcalc calculator, a web browser, or an Emacs session. It's the client application running in the window that determines what happens inside its windows.
Most people today run one of the desktop environments, KDE or GNOME. The desktops go further than a window manager in providing an integrated graphical environment where all applications and windows have a common look and feel. The desktop environments also include session management, for saving and restoring your work sessions. But if you look underneath, you'll still find the X Window System managing the display, and you'll find a window manager sitting between X and the desktop.
X is hidden two levels down from the desktop. For that reason, if you want to explore X further, it's helpful to run with just a window manager for a while, even if you end up going back to the desktop. (It's also interesting to note, by the way, that as long as KDE and/or GNOME are installed on your system, with their libraries, you can run their client programs from a window manager. I've been running the window manager fvwm for this article and using the KDE program ksnapshot to take screenshots.)
You can run the X server in two ways: with the X Display Manager (XDM), or by booting to the command line and starting X manually. There are too many distributions, each with its own configuration and startup procedures, for me to be able to provide general instructions for running the server in this article. But as an example, here's a quick way to set up a Fedora Core Linux system to boot to the command line so you can run the X server manually. This should work for other Red Hat-based distributions, and something similar should work for other distributions.
Your first step, while you are still in the desktop, is to use your favorite text editor to create a startup script in your home directory, if there isn't already such a script. In this case, since we are going to start manually, the file should be named .xinitrc; if we were going to use XDM, it would be .xsession. Be sure to make the file executable.
The last line of the file should run the window manager; in fact, that can be the only entry in the file. But it's useful if you want to do work, to set up at least a couple of xterm windows and maybe start a browser or any other application program that you use regularly. Here, for example, is my .xinitrc file:
#!/bin/bash xterm -sb -geometry 80x55+5+5 & xterm -sb -geometry 80x55+530+30 & oclock -geometry +1450+920 -bg ivory -fg blue & xscreensaver & exec fvwm
This file starts up two xterm windows, with sidebars and the specified
80x55 is the size of the window (80 characters wide and 55
lines long), and
+5+5 indicates where on the screen the upper-left
corner should be placed. Every line except the last one ends with an
to put them in the background so the next line can be executed. After
starting up a clock with an ivory background (the face) and a blue
foreground (the hands), and the xscreensaver program, the script
runs the window manager, fvwm.
Now we are ready to establish that we don't want to boot into X. As root, edit the file /etc/inittab and update the line that sets up the initial runlevel. We want it to start in runlevel 3 (multiuser mode) instead of runlevel 5 (X11 mode). Specifically, change the line
id:5:initdefault: to read id:3:initdefault:
Then when you restart the system, it will boot to a regular terminal window instead of to X11, displaying a login prompt. After you log in, you can start X:
As long as the startup script is running, the X server will also continue running. Since the last command in the script starts the window manager, X will continue to execute until the window manager is terminated, which terminates the script. Thus in effect, stopping execution of the window manager also stops the X server.
In fvwm, to stop the window manager, select Exit Fvwm from the root menu--the menu you get when you click on the root window (the background behind the other windows). Figure 1 shows an example of an fvwm root menu:
Figure 1. An fvwm root menu
Exit Fvwm is the last entry. When you click on it, a submenu asks whether you really want to quit fvwm, whether you want to restart fvwm, or whether you want to start a different window manager.
Figure 2 shows my screen running fvwm, based on the .xinitrc file we just saw, after I'd been working for a while, running commands in the xterm windows and starting some additional X clients.
Figure 2. Using fvwm to run commands and start X clients
The X server manages the display hardware. The server captures input events from the user via keyboard or mouse (or other input device) and passes the information to a client application that has requested it. It also receives requests from the application to perform some graphical action. For example, if you use your mouse to move a window on the screen, the X server passes the information to the window manager, which responds by telling the server where to reposition the window, and the X server performs the action. If the client is a calculator, such as xcalc, it might request that digits be displayed into the window as the user clicks on buttons to enter a number.
In any case, it is always the server that interacts with the hardware. Thus only the server software has to be hardware-specific. In fact, only the parts of the server that actually interact with the hardware need to be rewritten for X to be ported to new systems or to be usable with a new terminal or a new type of input device, for example. As long as the X clients are written to use the X Protocol, they can run on any system and communicate with the X server.
Getting X configured correctly used to be a real chore. You had to know all the hardware specifications for your monitor and video card, which isn't always easy to gather. Nowadays, though, your distribution's installation program is generally able to autodetect the hardware and find the right settings.
Nonetheless, you still might need to go into the configuration file to tweak a setting or two. Or you might simply be curious about how the file is set up.
You'll find the configuration file in /etc/X11, called xorg.conf for the X.Org server and XF86Config or XF86Config-4 for the XFree86 server. Click here to see what the xorg.conf file for my system looks like.
We don't have space to discuss the details of the file here. What's interesting to note is the way each piece of hardware is defined separately and then in terms of their relationships to each other.
The configuration file is divided into sections. For example, the Module section specifies the modules to be loaded when the X Window System starts up. There can be more than one of a particular section type. In this configuration are two InputDevice sections, one for the keyboard and one for the mouse. Each section has an Identifier, used to reference the section from another section.
At the top of the file, the ServerLayout section ties together
Keyboard0 as the combination of hardware for the
X server to manage. Then if you look at the end of the file, you can
Screen0 comprises the combination of
thus tying everything together neatly.
As we've seen, an X client is an application program that performs certain tasks, communicating with the X server using the X Protocol. The operations performed within a window can vary greatly, depending on the type of program running. Some windows wait for input from the user, functioning as terminals, calculators, or graphics applications. Other windows simply display information, such as the time of day or the system load.
The shaded area that fills the entire screen is called the root window. X client application windows are displayed on top of the root window. X treats windows as a hierarchy, with the root as the origin, or parent, of the application windows displayed on it. Conversely, the application windows are called children of the root window.
But the hierarchy goes further. Not only is the client window itself a child of the root window, but it also can have children of its own; for example, a drop-down menu, which itself is a window.
The window manager is the client application, with responsibility for managing client windows. There are a number of window managers to choose from, many with features that begin to approach those of a desktop. For information on many of the available window managers, see the Window Managers for X web site.
The window manager controls the general operation of the window system; in particular, it controls the geometry and aesthetics of your X display. With the window manager you can change the size and position of windows on the display, reshuffle windows in a window stack, and so on.
Figures 1 and 2 are screenshots from my fvwm-managed system. If you are using another window manager, the X display will have that window manager's appearance. In fact, because X is so customizable, even two users running the same window manager are likely to have screens that look very different.
fvwm is compliant with the Inter-Client Communication Conventions Manual (ICCCM). The ICCCM is a standard that defines interactions between X clients, including client interactions with the window manager. It defines basic policy that is intentionally omitted from X itself, such as the rules for transferring data between applications and for transferring keyboard focus. Window managers and other applications that follow the ICCCM should be able to coexist and work together on the same server, even if they were written using different toolkits. This capability explains why you can, for example, run KDE applications on a GNOME desktop or with fvwm.
X clients are designed to be customized by the user, by setting the value of variables known as properties. Most clients come with a default set of properties; the defaults can be overridden on a systemwide basis or individually by the user. For a user, client properties can be specified on the command line, but more conveniently, they can be set as resources in a file generally called .Xresources in your home directory. Here, for example, is my .Xresources file:
!--------------------------------------- ! XTerm defaults !--------------------------------------- XTerm*saveLines: 500 XTerm*reverseWrap: True XTerm*scrollKey: False XTerm*scrollBar: True XTerm*geometry: 80x50 !--------------------------------------- ! emacs defaults !--------------------------------------- emacs*geometry: 80x66
After setting up the .Xresources file, you can load the resources into the X server using a program called xrdb (the X resource database manager). Typically, you do this in the startup script. Looking again at our .xinitrc script, we can add a call to xrdb:
#!/bin/bash xrdb -load $HOME/.Xresources xterm -sb -geometry 80x55+5+5 & xterm -sb -geometry 80x55+530+30 & oclock -geometry +1450+920 -bg ivory -fg blue & xscreensaver & exec fvwm
Now, the next time you start X, your resource settings will be loaded
into the resource database and made available to the appropriate X
clients. Note that the xrdb command line is not followed by
is because it runs and completes, so the script can proceed to
execute the next command.
Now you can run xrdb again with the
-query option to see what options
are currently set:
$ xrdb -query XTerm*saveLines: 500 XTerm*reverseWrap: True XTerm*scrollKey: False XTerm*scrollBar: True XTerm*geometry: 80x50 emacs*geometry: 80x66
The man page for most X client applications gives the names of the resources you can set for that application.
A separate customization file for fvwm called .fwwm2rc is also kept in your home directory. By editing the .fwwm2rc file, you can modify aspects of the window manager's operation such as the contents of menus, and the keyboard and mouse button sequences used to invoke actions. Other window managers have comparable configuration files. For more information, see the fvwm2 man page. (Note that the current version of fvwm is fvwm2. You can run fvwm2 instead of fvwm in your startup file; fvwm is a symbolic link to fvwm2.)
The X Window System is fascinating and complex. We've only touched on some of its major features. In the last section, I've listed a few resources for finding additional information.
See the links under the heading "Base Technology" on the X.Org web site for explanations of X architecture.
The X man page is not exactly light reading, but it has plenty of good information.
The Linux Documentation Project has a number of how-tos about X, including "The X Window System Architecture Overview HOWTO" and "The X Window User HOWTO."
Ellen Siever is a writer and editor specializing in Linux and other open source topics. In addition to Linux in a Nutshell, she coauthored Perl in a Nutshell.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.