Tải bản đầy đủ - 0trang
11 Displays, Screens, and Xinerama
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 themselves 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.
1.12 Display Specifications
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:
The following list describes each element in a displayspec:
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)
The display number, greater than or equal to zero
An optional screen number within the display; screens are numbered starting at
Here are some examples:
Display 0 on the local computer, connected by a local connection scheme
Display 3 on the local computer, connected by TCP/IP
Display 2 on the TCP/IP host stealth.oreilly.net
Chapter 1: Introduction to the X Window System
Display 4, screen 3 on the host with IPv4 address 126.96.36.199
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
1.13 TCP/IP Ports
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.
1.14 Local Connection Mechanisms
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
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).
1.14 TCP/IP Ports
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
1.15 Server Extensions
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):
Permits client requests over 256 Kb, necessary to draw complex images.
Offers shared memory for local communication of images.
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
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).
Chapter 1: Introduction to the X Window System
Displays Power Management Signalling. Enables the X server to reduce monitor
power consumption when not in use (Section 3.11).
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!).
Low-Bandwidth X. Used with lbxproxy to reduce bandwidth requirements and
latency for remote clients (Section 13.11).
The eye-candy extension! MIT-SCREEN-SAVER informs screensavers when to
start and stop (Section 14.3).
Stands for rotate and resize. Notifies clients when the display is resized to a new
resolution or rotated (useful on tablet PCs and LCDs on pivot mounts) and
enables the hot-plugging of monitors (Section 5.2).
Permits X events to be recorded for later analysis or playback. Used to automate
application testing and provide macro facilities.
Provides a digital image composition model. Render simplifies tasks such as
alpha blending (combining partially transparent images) and high-quality antialiased text display (Section 11.1).
Divides clients into two categories—trusted and untrusted—and prevents
untrusted clients from accessing data held for trusted clients. Properly used, this
can reduce the risk of compromise due to actions such as keystroke logging (to
steal passwords) or remote screen dumping (to view sensitive information displayed on the screen). ssh now supports this extension (Section 13.10).
Enables nonrectangular windows. The xeyes and oclock clients provide a good
demonstration of this capability.
Makes it possible to synchronize the X display with external events—for example, keeping a movie soundtrack synchronized with the picture.
Provides support for specialized input devices such as graphics tablets, dial
boxes/control surfaces, and 3D trackballs.
1.15 Server Extensions
Enables complex keyboard mapping and configuration (Section 12.1).
Extends the X protocol to simplify performance benchmarking.
Single-screen, multimonitor support (Sections 1.11 and 4.2).
Enables video streams, such as those from a video camera or TV tuner card, to
be converted, transformed, and then overlaid on the X display. This is done with
hardware support and can dramatically improve video performance (Section
Utilizes hardware support for video decompression—useful for DVD viewing
and other MPEG video playback.
1.16 Where to Draw the Line: Kernel Versus UserSpace Drivers
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.
Chapter 1: Introduction to the X Window System
Starting a Local X Server
One Size Doesn’t Fit All
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