X Power Tools | O'Reilly Media

BUY THIS BOOK

Print Book $39.99

PDF $31.99

Safari Books Online

What is this?

Print Book £24.99

What is this?

Looking to Reprint or License this content?

Tell a friend

X Power Tools

By Chris Tyler
Book Price: $39.99 USD
£24.99 GBP
PDF Price: $31.99

Cover | Table of Contents | Colophon

Chapter 1: Introduction to the X Window System

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The X Window System is a portable, network-based display system. That short definition contains three of the keys to X's success:

Portable: The X Window System is primarily used on Unix, Linux, and BSD systems, but it can also be used on Microsoft Windows, Mac OS X, and many other systems—in fact, it can be used on just about any modern operating system. It supports a wide range of hardware, from PDAs and standalone terminals to multimonitor workstations and information displays. Technology may be mixed and matched to suit user preferences, needs, and budget.
Network-based: Programs can display anywhere on the network, and windows from programs running on machines several time zones apart can be displayed side-by-side on one screen. With X, users have complete freedom to work wherever they want.
Display system: X is not a graphical user interface (GUI), but it provides a solid foundation for building one. GUI developers can escape from dealing with the intricacies of the display hardware and focus on user interface design, and legacy applications written for decades-old X-based GUIs will continue to work with modern ones.

Although most users of Unix (or Linux, or FreeBSD, or Darwin) often take X for granted, a good understanding of how it works opens up a world of possibilities, from speeding up remote access to building personal video recorders to configuring multiuser computers and information kiosks.

In this book, I assume that you have used X and that you have a basic understanding of Unix. This chapter introduces some of the history and basic concepts of X as well as the hardware technology used in modern displays; this sets the stage for the rest of the book, which uses a hands-on approach.

X originated at MIT in 1984. It was a part of Project Athena, a campus-wide, crossplatform system, and it was loosely based on the W Window System from Stanford.

Before long, Unix vendors started to gain an interest in X. They realized that X would make it easier to port graphical applications to new hardware, which in turn would attract independent software vendors (ISVs)—and the more software became available, the more systems would be sold.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The X Window System

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The X Window System is a portable, network-based display system. That short definition contains three of the keys to X's success:

Portable: The X Window System is primarily used on Unix, Linux, and BSD systems, but it can also be used on Microsoft Windows, Mac OS X, and many other systems—in fact, it can be used on just about any modern operating system. It supports a wide range of hardware, from PDAs and standalone terminals to multimonitor workstations and information displays. Technology may be mixed and matched to suit user preferences, needs, and budget.
Network-based: Programs can display anywhere on the network, and windows from programs running on machines several time zones apart can be displayed side-by-side on one screen. With X, users have complete freedom to work wherever they want.
Display system: X is not a graphical user interface (GUI), but it provides a solid foundation for building one. GUI developers can escape from dealing with the intricacies of the display hardware and focus on user interface design, and legacy applications written for decades-old X-based GUIs will continue to work with modern ones.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The History of X

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

X originated at MIT in 1984. It was a part of Project Athena, a campus-wide, crossplatform system, and it was loosely based on the W Window System from Stanford.

After a brief flirtation with restrictive licenses, version 11 of the X Window system was released in 1987 under the MIT license, and a vendor-neutral group called The X Consortium was formed to manage development. This was one of the earliest examples of an open source project. In fact, it predates the term open source by more than a decade. Each vendor used the sample code from the X Consortium as a starting point and implemented a server tuned for their particular display hardware and operating system.

Control of X passed from group to group until 1999, when X.org was established by The Open Group to manage the technology. Unfortunately, official work on X had almost come to a standstill by that point.

However, one particular implementation of X for PCs, named X386, piqued the interest of many developers in 1992. When distribution of a commercial version of X386 began, the open source version was renamed XFree86 (say both names aloud to realize the pun). Eventually, most X innovations were made within the XFree86 project rather than coming from the official guardians of the X standard.

But internal politics and a rigid organizational structure took their toll on the The XFree86 Project, Inc, and after a license dispute in 2003, some key developers decided that they'd had enough. They moved development back to the almost-defunct X.org, formed The X.org Foundation, and shifted work into high gear. Most open source operating system distributions adopted the X.org server in 2004.

In the end, active X development wound up where it had started, the successor to the XFree86 project replaced the sample implementation of X technology, and a revitalized developer community started to once again steadily advance the state of the technology.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Renaissance: New X Versus Old X

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

I recently skimmed through the 1994 book X User Tools, by Linda Mui and Valerie Quercia (O'Reilly), and the 1993 UnixWare user documentation. It was a fun and nostalgic stroll down memory lane, because the X Window System I used in the early-to-mid 90s was very different from X today. Many of the changes have been introduced so gradually that it's only by looking at old screen dumps that I realize how far we've come.

I have started to think of X development in terms of two eras: Old X (1984–1996) and New X (2000–present). Old X was characterized by the development of the core protocols, essential extensions, and Xt-based toolkits. New X development was kicked off by the release of the RENDER extension in 2000, which, along with Xft, OpenGL, the COMPOSE extension, and non-Xt toolkits (Qt and KDE), is causing large portions of the core X protocol to fall into disuse. Between these two eras, X development almost came to a standstill.

Here is a summary of some of the key differences in the technology of the two eras:

Element	Old X	New X
Fonts	Bitmapped fonts and scalable fonts without anti-aliasing, rendered by the core font capabilities in the server.	Scalable fonts with full antialiasing, managed on the client side by fontconfig, and displayed by the Xft library using the RENDER extension.
Desktop environments	No standard desktop environments (though HP Vue morphed into CDE and made a late appearance). Consequently, window managers played a much larger role than they do today. Panel bars were rare— icons for minimized windows sat directly on the desktop (or, sometimes, in a separate icon box window). Clients were usually started through root-window menus or by typing commands in an xterm.	Two widely used desktop environments (KDE and Gnome) and a lightweight desktop (Xfce) with well-integrated root desktop, menu, and panel-bar operation.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

X by Any Other Name

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The X Window System goes by many different names, and sometimes this is a source of confusion. According to the manpage, X should be referenced using one of these names:

X
X Window System
X Version 11
X Window System, Version 11
X11

Notice that "X Windows" is not on that list; this omission was originally due to concern about confusion with Microsoft's Windows product line.

This has been used as a shibboleth for many years; anyone referring to "X Windows" was considered an outsider or a beginner. Fortunately, this pedantry is waning, but you should probably avoid saying "X Windows" if you find yourself in the company of an industry old-timer.

The version number is almost never mentioned in modern usage, since the previous versions were experimental, and Version 11 has been in use for almost two decades (though the release number keeps going up).

The dominance of the X.org implementation has led a number of people to refer to X itself as Xorg or X dot org.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Seven Layers of an X-based GUI

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

It is Unix tradition to assemble solutions out of many small programs rather than to use a single, monolithic program. This approach gives more flexibility, since these smaller building blocks may be combined in different ways to meet different needs.

GUIs based on the X Window System follow this same philosophy—they're built in layers that can be mixed and matched as needed.

shows a simple model of the seven layers found in most X-based GUIs.

Figure : The layers of an X-based GUI

Elements at the top of the diagram are the most visible and important to the user, and the components at the bottom of the diagram are the least visible. From the bottom up, these layers are:

Network Transport: Enables the other layers to communicate. This layer almost always consists of TCP/IP plus a faster connection scheme for local clients (Section 1.14), but many older or proprietary network transports can be used, including IPX/SPX and DecNET.
X Window Server: Consists of the software that manages the display (which normally consists of a keyboard, video screen, and mouse) and runs on the computer connected to the display hardware. All of the layers above the X server are considered clients of that server and may be located anywhere on the local network, or even over the Internet.
Display manager: Enables a user to log in to the system graphically. Most display managers ask the user to type his user ID and password, but it's possible to use almost any authentication scheme, including biometric scanning.
Session manager: Tracks application state across login sessions, starting standard clients such as the window manager and desktop environment components, restarting applications that were active at the end of a previous session, and optionally restarting applications if they crash.
Window and Compositing manager: Manages window placement and provides window decorations. This includes window title bars, borders, and controls for common operations such as resizing, maximizing, minimizing, moving, and closing windows. When the COMPOSITE extension is available, the window manager also acts as the compositing manager. The X developers tried separating them, but in order to work really well, the compositing manager needs access to information about the windows that only a window manager knows. A window manager is considered to be a special class of client, and only one can be active on a display at a time.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Where Is the Server?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In most network terminology, the client system is the one that is on your desktop, in your hand, or on your lap, and the server is the computer in the closet down the hall.

But in X terminology, the computer in front of you runs the server, and the client programs may be located on the computer in the closet.

As confusing as this may seem at first, it makes sense if you think in terms of the resource being served. A file server is located where the files are stored; a print server is located at the printer; and a display server is located at the display.

The specific resources managed by an X server include video cards and monitors, pointing devices (such as mice, trackpads, and touchscreens), and keyboards. These are each located at the physical machine running the X server.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Why Windows Look and Act Differently

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The programs that access and use display resources are the clients. They may be on the same computer as the server, or they may be located down the hall, or they may be on the other side of the planet.

One of the early tenets of the X Window developers was that X should provide a mechanism for implementing a GUI, but should not impose any policy on how that GUI should operate. This has been both a blessing and a curse throughout the history of X.

Since X does not define policy, the look and feel of applications has been left up to application and toolkit developers, and there is a tremendous variation between programs. The advantage is freedom to experiment and innovate; the disadvantage is confusion for users.

On one of my systems, I have three different calculators available: xcalc, kcalc, and gnome-calculator, as shown in .

As you can see from this screen dump, each calculator looks different: the fonts, colors, button sizes, menu options, icons, and status bar vary from program to program. They also use different visual effects when buttons are pressed.

Fortunately, the toolkit developers have assumed responsibility for many policy issues, and programs based on the same toolkit generally operate in a consistent way. Programs using different toolkits still behave differently, but the most popular toolkits have converged in their look and feel; notice the similarities between the 3D buttons and the fonts used by kcalc (center) and gnome-calculator (right).

Figure : xcalc, kcalc, and gnome-calculator

One more thing to note in : each window's title bar, border, and window controls are the same—because they are being drawn by the window manager, not the individual application programs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Toolkits and Desktop Environments

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are three main toolkits currently in use, and desktop environments have been based upon each one:

Toolkit	Original programming language	License	Open source	Desktops built with this toolkit
GTK+	C	GPL	Yes	Gnome, Xfce
Qt	C++	GPL	Yes	KDE
Motif/OpenMotif	C	Open Group Master Software License/Open Group Public License	No	CDE

Most of these desktop environments are distributed with a display manager, window manager, and some application clients, but you can mix and match components from different environments. The use of one desktop environment does not prevent you from using applications built with another toolkit or distributed with another desktop environment, so you can use KDE along with GTK+ apps, or Xfce with Motif applications.

Almost all new development is now based on the GTK+ and Qt toolkits, primarily because they are open source (http://opensource.org) and therefore more accessible to developers.

However, Motif continues to be an important toolkit for legacy applications, especially in some financial and scientific niche markets. Motif and OpenMotif are essentially the same product, distributed under different licenses. While the Open Group Public License does permit OpenMotif to be freely distributed, this is for use only with open source operating systems such as FreeBSD or Linux , so the license does not meet the Open Source Definition (http://opensource.org/docs/osd

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Role of Freedesktop.org

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There's more to a desktop than just a display—there's also sound, filesystem integration, on-the-fly hardware discovery, and much more. All of these bases must be covered in order to produce a desktop environment that can compete with commercial offerings such as Microsoft Windows or Mac OS X.

Recognizing this, developers have rallied around freedesktop.org, creating an informal consensus-building forum for desktop-oriented technologies. Freedesktop.org (the web site address is the same as the project's name) hosts much of the work of the revitalized X.org project, coordinates standards between Gnome and KDE, and supports the development of complimentary technologies such as D-BUS and HAL.

freedesktop.org's lightweight organization and focus on collaboration have made it the centerpiece for most desktop-oriented open source software development.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Display Hardware

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Let's take a look at the hardware typically managed by an X server. It generally has the following components:

Zero or more pointing devices (mice, trackballs, touchscreens).
Zero or more keyboards.
One or more video cards, each connected to one or more monitors.

The entire collection of hardware is called a display and is managed as a single unit, intended to be used by one person. It is possible to have multiple displays connected to one computer, but a separate X server needs to be run for each display.

Pointing devices fall into two general categories: relative and absolute:

Relative pointing devices: These send only movement information to the display. A new pointer position is calculated by taking the previous pointer position and updating it with the indicated movement. Mice, trackpads, and trackballs fall into this category.
Absolute pointing devices: These send an exact screen position to the display. Touchscreens, graphics tablets, and light pens are all absolute devices.

It is possible to have multiple pointing devices connected to one display. This is common on laptops; some have two built-in pointing devices, and some users add a traditional mouse to compliment a built-in pointing device. The devices act in parallel, and any can be used to move the pointer on the screen (Section 4.8).

A display is rarely configured without a pointing device, but this may be done for an information-only display that does not permit user interaction.

Pointing devices are connected to the computer using a USB, PS/2, serial, or blue-tooth connection. The data rate is very low, so USB pointing devices always run at low speed (1.5 Mbps) even when they are certified to USB 2.0 standards. PS/2 and serial interfaces are electrically identical but have different connectors; you can buy adapters to convert one to the other.

A few years ago, there were dozens of communication protocols used by mice. Fortunately, almost all mice now use an extended version of the PS/2 mouse protocol, regardless of how they are connected, though graphics tablets, touch screens, and the other more exotic pointing devices still use unique protocols.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Displays, Screens, and Xinerama

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In X terminology, a display comprises the user interface for one person. That usually means one keyboard, pointer, video card, and monitor, but for some applications, more video "real estate" is required. Thus, a display can have multiple video cards and monitors, perhaps with different capabilities and resolutions—but this is where the terminology gets tricky.

All of a display's video cards and monitors can be combined to act like one giant video monitor. This approach is called Xinerama (Section 4.9) as a tribute to the old Cinerama multiprojector wide-screen movie format. Xinerama permits windows to span monitors and works especially well on multipanel LCD displays, video walls, or video projectors.

Alternately, a display's video cards and monitors may be configured as separate screens . Each screen is individually addressable, so windows can be directed to display on a specific screen. It is not possible to move windows between screens nor to have windows span screens, but the mouse pointer can be moved between screens. The use of screens predates Xinerama, but it is still useful for some dual-monitor applications, such as presentations where one monitor is used for control and setup and the second monitor displays live output to the audience. By using a two-screen configuration instead of Xinerama, windows from the control screen will be prevented from straying onto the publicly-visible display.

Some window managers, such as the LessTif version of the Motif Window Manager MWM, are not capable of managing multiple screens and will only register them-selves as the window manager for one screen. On the other hand, some toolkits are not aware of Xinerama, so dialogs that are intended to be positioned in the center of a display always display in the middle of the Xinerama display—and therefore always span across monitors in a dual-monitor Xinerama configuration (which is very, very annoying).

Each display (regardless of the number of screens involved) is managed by exactly one X server process.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Display Specifications

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Since X clients can connect to a display anywhere on the network, it is necessary to have some way of specifying the display to be used. This is done using a display specification (or displayspec).

A displayspec takes this form:

          host:display[.screen]

The following list describes each element in a displayspec:

host

The name or network address of the system running the X server. This may be:

A DNS hostname or IP address
Blank, or the word unix, indicating a local host connection (Section 1.14)
A DecNET, IPX/SPX, or other machine designation (extremely rare)

display

The display number, greater than or equal to zero

screen

An optional screen number within the display; screens are numbered starting at zero

Here are some examples:

:0: Display 0 on the local computer, connected by a local connection scheme
localhost:3: Display 3 on the local computer, connected by TCP/IP
stealth.oreilly.net:2: Display 2 on the TCP/IP host stealth.oreilly.net
172.250.12.7:4.3: Display 4, screen 3 on the host with IPv4 address 172.250.12.7

The displayspec can be passed to clients as an option value:

	$ xclock -display displayspec

However, it is more common and convenient to use the DISPLAY environment variable. If you are using a shell that follows the Bourne syntax(sh, bash, ksh, zsh, or ash), you can set and export the DISPLAY variable like this:

	$ export DISPLAY=displayspec

If you are a csh aficionado, use:

	% setenv DISPLAY displayspec

Once the DISPLAY variable has been set, any new clients started will connect to the specified display by default. (Command-line options take precedence over the DISPLAY variable.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

TCP/IP Ports

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Each X display uses a unique TCP/IP port so that multiple servers on the same system do not conflict. All of the screens managed by one display are accessed through the same port; screen selection is accomplished through the X protocol.

The standard port for an X server is 6000+display, so display :0 uses port 6000, and display :15 uses port 6015. Since these port numbers are over 1024, the kernel permits anyone to open them—so you don't need to be root to run an X server. Large display numbers may conflict with other services (such as IRC at port 6667), so it is best to keep display numbers under 100.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Local Connection Mechanisms

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

TCP/IP is a great network transport, but it's overkill for connecting programs running on the same computer. Most X servers provide a faster alternative for local connections.

Unfortunately, there are at least five different local connection schemes in use, including Unix domain sockets, named pipes, and various types of Streams pipes. Open source operating systems use Unix domain sockets without exception.

A displayspec with a blank host field will automatically select the default local connection scheme; if the default isn't a Unix domain socket, then some systems permit a host value of unix to force a domain socket to be used.

Unix domain sockets for the X server are created in /tmp/.X11-unix and are named according to the display number (therefore, /tmp/.X11-unix/X0 is the Unix domain socket for local display :0).

After a local connection has been established, the client and server can negotiate the use of shared memory for faster communication of large blocks of data; this requires the MIT SHM extension.

Binaries compiled for one platform but executed on another may not interpret a blank hostname field in the displayspec correctly. For example, binaries compiled for SCO Unix may default to a Streams mechanism. When running under Linux using the iBCS compatibility layer, this will cause a problem, because Linux doesn't support Streams. In this case, a hostname value of unix should force the use of Unix domain sockets; as a last resort, the TCP/IP local loopback mechanism can be used by specifying a hostname of localhost (however, this incurs the extra overhead of the TCP/IP stack—twice).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Server Extensions

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The X11 protocol was designed to be enhanced by adding extensions to the X server. Clients can query the server to find out what extensions are available. This has enabled many features to be added through the years without significant changes to the core protocol (which explains why we're still using version 11!).

Extensions may be compiled in to the X server, or they may be loaded as modules. Because their presence is optional, the X server can be slimmed down for use on small machines by building it with a smaller set of extensions.

Here are some of the key extensions in widespread use (upper-and lowercase names are those reported by the extensions themselves using xdpyinfo (Section 6.2):

MIT-BIG-REQUESTS: Permits client requests over 256 Kb, necessary to draw complex images.
MIT-SHM: Offers shared memory for local communication of images.
Composite: Enables off-screen rendering of windows, which are then combined (composited) into the final screen image by hardware under control of a compositing manager. This is usually integrated into the window manager. During composition, images can be distorted, blended, and resized, so the extension provides an easy way to add drop shadows, window transparency, icons, and thumbnails that are "live," smooth window resizing, and many other 2D and 3D visual effects.
DAMAGE: Informs a client when one part of the display has been updated. Reduces unnecessary drawing and improves the efficiency of applications such as VNC (Section 14.1).
DPMS: Displays Power Management Signalling. Enables the X server to reduce monitor power consumption when not in use (Section 3.11).
GLX: OpenGL extension for X11. Enables clients to send OpenGL 3D commands to the X server, which then passes them on to 3D video hardware (or performs the 3D operations in software if necessary—which is very slow!).
LBX: Low-Bandwidth X. Used with lbxproxy to reduce bandwidth requirements and latency for remote clients (Section 13.11).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Where to Draw the Line: Kernel Versus User-Space Drivers

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The operating system kernel is usually responsible for managing all of the system hardware, and normal user-space programs access hardware only through the OS. This clear-cut distinction between the kernel and user-space programs has been very difficult to maintain when implementing X servers.

The problem is that video cards vary enormously in terms of their GPU capabilities and general architecture. It's hard to create a simple, well-defined interface between a video driver in the kernel and an X server in user-space that will work well for all video cards, though several attempts have been made. And of course the X server is too large and complex to safely place it directly into the kernel.

As it stands now, most kernel/X server combinations—including Linux with the X.org server—pretty much give the X server free reign when it comes to video card access, though some of the card drivers (such as the NVIDIA closed-source driver) use a small kernel module to assist them.

This will likely change in the future. The X server may eventually operate as one (of perhaps many) OpenGL clients, removing direct hardware access from the X server entirely. The Xgl server provides a preliminary implementation of this approach.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Starting a Local X Server

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

An X server can be started in different ways to suit different types of use. In this chapter, we'll examine the techniques available for starting X and discuss the best approach for some common scenarios, including:

Presenting a graphical login display (Section 2.4)
Configuring a home system with two graphical login displays, so that two people can alternately use it without disturbing each others' work (Section 2.7)
Starting X on a server system only when it is really needed, in order to conserve system resources for more important uses (Section 2.9)
Starting an X server that is displayed within another X server (Section 2.11)

We'll also take a look at how to use Virtual Terminals (Sections 2.2 and 2.10), how to simulate a mouse when a bad configuration leaves you without one (Section 2.12), and how to terminate X (Sections 2.13 and 2.14).

Linux, FreeBSD, and many other modern Unix kernels support a virtual terminal (VT) (or virtual console) capability, which provides independent virtual video cards. The monitor, keyboard, mouse, and physical video card are associated with only one VT at a time, and each virtual video card can be in a different display mode—some may be in character mode while others are in graphical mode. This enables multiple X servers and nongraphical sessions to be active at the same time.

To switch virtual terminals on Linux, press Ctrl-Alt-Fx(where Fx is a function key from F1 through F12, corresponding to a virtual terminal from VT1 to VT12; you can also use Alt-Fx if the current VT is in character mode). When you are connected to a virtual terminal that isn't running an X server, you can use Alt-LeftArrow to go to the previous VT and use Alt-RightArrow to switch to the next VT. Some Linux distributions also configure the Windows key to advance to the next VT; you can also switch virtual terminals using the switchto or chvt commands (Section 2.10).

By default, most Linux distributions boot up with six nongraphical logins on VT1– VT6 and one X server running on VT7.

FreeBSD provides a very similar VT capability, except that the VTs are numbered starting at zero, and the key combination to switch VTs when in character mode is Alt-Fx. Virtual terminals are numbered one off from Alt keys, because there is no F0 key. Therefore, if you're on VT3 in character mode and press Alt-F1, the kernel will take you to VT0.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

One Size Doesn't Fit All

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Presenting a graphical login display (Section 2.4)
Configuring a home system with two graphical login displays, so that two people can alternately use it without disturbing each others' work (Section 2.7)
Starting X on a server system only when it is really needed, in order to conserve system resources for more important uses (Section 2.9)
Starting an X server that is displayed within another X server (Section 2.11)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Virtual Terminals

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

By default, most Linux distributions boot up with six nongraphical logins on VT1– VT6 and one X server running on VT7.

System V Release 4.x systems such as UnixWare use Alt-SysReq followed by Fxto switch virtual terminals.

Although most kernels support more than 12 virtual terminals, this capability is rarely used because you can't usually use the keyboard to go directly to higher-numbered VTs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Starting a Raw X Server Manually

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The simplest way to start an X server is also the least-used technique: simply type the name of the server at a shell prompt:

$ X

Most Unix command and program names are lowercase, but the X server is an exception. You must enter "X" as a capital letter.

X is actually a symbolic link to the installed server binary, which is named Xorg if you're using the X.org server, XFree86 if you're using the XFree86 server, and so on.

If an X server is already running on display :0, you will get an error message, because the network port will already be in use. In that case, you can give the new X server a different display number:

	$ X :1

By default, the X server will start on the first unused VT (usually VT8). You can request a specific VT by specifying it on the command line:

	$ X :1 vt10

You can also specify that a particular configuration file should be used, or a particular ServerLayout within a configuration file:

	$ X :1 -config configFile
	$ X :1 -layout layoutName

The downside to starting the X server this way is that no clients are started. Until you start some manually, you'll be left staring at a blank screen with only a mouse pointer to amuse yourself.

You can start the X server and a client at the same time like this:

	$ X :1   -terminate &  sleep 2 ; DISPLAY=:1 xterm

The -terminate option will cause the X server to exit when the last client disconnects, and the sleep 2 option ensures that the X server has time to start before the xterm client attempts to connect to it—not usually required, but it's good practice to ensure that your commands will work reliably. Note that this command line does not start a window manager or a desktop environment, so you will not be able to move or resize the xterm window, start additional programs (except by typing in the terminal), or set the keyboard focus.

The advantage of starting X directly is that you have precise control over the X server startup options and the list of clients displayed, which is perfect for a kiosk.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using a Display Manager to Start the X Server

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One of the possible layers of an X-based GUI is a display manager, which is the graphical equivalent of the login program. It is usually configured to start one or more local X servers to present a greeter dialog that collects the user's name and password. Once the user is authenticated, the display manager starts some preconfigured clients—typically a session manager that goes on to start a window manager and desktop environment such as KDE or GNOME. Many display managers let you select a session type, which will in turn activate a specific desktop environment. When the user exits the client(s), the process starts over again.

Three display managers are in common use. The biggest difference between them is the toolkit upon which they are built:

GDM: GNOME Display Manager (built on GTK)
KDM: KDE Display Manager (Qt)
XDM: X Display Manager (Xt)

KDM and GDM offer some advanced features not present in the older XDM program, such as a picture-based face browser and the ability to select the desktop environment that will be loaded once the user authenticates.

You may be able to recognize the display manager used on your system by its appearance, since each toolkit has a distinctive look. Alternately, you can search the process table to see what's running, using the following:

	$ ps -e | grep '[gkx]dm'

If you prefer BSD-style arguments, or if your version of ps permits these arguments only, use ps ax in place of ps -e.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Enabling or Disabling the Display Manager at Boot Time

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many commercial Unix systems and Linux distributions borrow a boot technique pioneered in Unix System V: the use of runlevels to start and stop software sets.

lists the standard runlevels.

Table : The standard runlevels observed by most System V Unix variants and Linux
Runlevel	Description
0	Halt
s,S	Single-user mode: no per-runlevel scripts executed; /etc/inittab not required (emergency use only)
1	Single-user maintenance mode
2	Multiuser, nonnetworked mode (the default runlevel for Debian-based systems, including Ubuntu, but rarely used on other systems)
3	Multiuser, networked mode
4	Unused
5	Multiuser, networked mode with local graphical login
6	Reboot
7,8,9,a,b,c	Unused

Runlevel s or S is a special case: it's used internally by init and normally shouldn't be entered directly by the user, who can enter runlevel 1 for single-user mode instead. But it has a special quality: it's the only runlevel that does not require /etc/inittab and is therefore useful in emergency recovery situations.

When you boot a Linux or Unix system into runlevel 5 (the default for most distributions except Debian/Ubuntu when an X Window server is installed), the display manager will start automatically. To prevent this, you can boot your system into run-level 3 by editing the kernel boot parameters, either temporarily or permanently.

To temporarily change the boot into a different runlevel if you are using the grub bootloader, take the following steps:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What Started the Display Manager?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Depending on your system configuration, the display manager may be started directly by init, or through an init script. It's useful to know how the display manager starts so that you can make changes and so that you know what will happen if the display manager exits (or crashes!).

In some Linux distributions, the display manager is directly started by init. For example, in Fedora's /etc/inittab, you will find this entry:

	# Run xdm in runlevel 5
	x:5:respawn:/etc/X11/ prefdm -nodaemon

In the second line, the second field specifies that this command is executed only in runlevel 5, and the third field directs that it is to be respawned (executed again) if it exits.

The script /etc/X11/prefdm will execute /usr/sbin/autologin to automatically log in one user if that feature has been set up. Otherwise, it will start one of the display managers ( GDM, KDM, or XDM) depending on the specification in /etc/sysconfig/desktop. If that file does not exist, then the first display manager found in alphabetical order will be used.

Since init has been set up to respawn the display manager automatically, it is relatively easy to load and test changes to the display manager configuration file—just kill the display manager! If you're using XDM or KDM, you can kill the display manager by name:

	# killall xdm

Killing the display manager will also kill all the display manager's child processes, including X servers—so if you do this through the graphical interface, expect your session to disappear!

GDM is a wrapper script for gdm-binary , so if your system uses GDM, you'd have to kill the display manager with the following:

	# killall gdm-binary

Alternately, you can restart GDM immediately using its restart script:

	# gdm-restart

Or you can specify that a restart should take place as soon as everyone is logged out:

	# gdm-safe-restart

In FreeBSD, the display manager is started by init but the configuration information is in /etc/ttys instead of /etc/inittab:

	ttyv8 "/usr/sbin/xdm -nodaemon" xterm on secure

The fourth field can have a value of on or off to enable or disable the display manager.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Starting Multiple X Servers Using a Display Manager

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

On a home computer, it can be useful to configure the display manager to start two or more X servers. You can then flip between them using the virtual terminal mechanism (Section 2.2).

A few years ago, I used this configuration on my home computer, so that when I wasn't using it, other members of my family could change VTs and log in without disturbing my work. When they finished, I would just switch back to my VT and continue where I left off. (Now I've extended this configuration by adding additional video cards, keyboards, mice, and monitors so we can log in simultaneously.)

XDM and older versions of KDM (pre-3.4) use the Xservers file to configure the number of servers started by the display manager. The location of this file varies; try /etc/X11/xdm/Xservers or /opt/kde3/share/config/kdm/Xservers.

This is a fairly standard Xservers file:

	# $Xorg: Xserv.ws.cpp,v 1.3 2000/08/17 19:54:17 cpqbld Exp $
	#
	# Xservers file, workstation prototype
	#
	# This file should contain an entry to start the server on the
	# local display; if you have more than one display (not screen),
	# you can add entries to the list (one per line). If you also
	# have some X terminals connected that do not support XDMCP,
	# you can add them here as well. Each X terminal line should
	# look like:
	#       XTerminalName:0 foreign
	#
	:0 local /usr/bin/X

Lines that start with # are comments. The active line, at the bottom, specifies that display 0 is a local X server, and gives the command line to be used to start that X server.

To start additional X servers, simply add lines at the bottom of this file:

            :1 local /usr/bin/X :1 vt8
	:2 local /usr/bin/X :2 vt9

Although it's not strictly necessary to specify the VT on these lines, it's a good idea, because then you will confidently know which display is paired with which VT.

If you wish to specify a different configuration file for one of the X servers, you can add a -config argument to the command:

            :3 local /usr/bin/X -config configgile :3 vt10

This must all appear on a single line in the configuration file.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Starting Additional X Servers on Demand Using a Display Manager

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Recent versions of both GDM and KDM are capable of starting additional X servers on demand. This is useful when you occasionally want to use multiple X servers but don't want the extra overhead when a single X server only is in use. The GNOME developers call these additional servers flexible servers; the KDE folks call them reserve servers.

The GDM display manager provides a command-line utility, gdmflexiserver, which communicates with a running gdm process and instructs it to start a new X server