X(X) X Version 11 (11 July 1990) X(X)
NAME
X - a portable, network-transparent window system
SYNOPSIS
X is a network-transparent window system developed at MIT
that runs on a wide variety of computing and graphics
machines. The core distribution from MIT has both client
and server support for the following operating systems:
4.3+tahoe
Ultrix 3.0 FT2 (also compiles under Ultrix 2.0)
SunOS 3.4
HP-UX 6.01
Apollo Domain/IX 9.7 (and 9.6 according to its developers)
IBM AOS 4.3 (according to its developers)
A/UX 1.0
SCO UNIX System V
Commercial implementations are also available for a much
wider range of platforms.
The X Consortium requests that the following names be used
when referring to this software:
X
X Window System
X Version 11
X Window System, Version 11
X11
X Window System is a trademark of the Massachusetts
Institute of Technology.
DESCRIPTION
X window system servers run on computers with bitmap
displays. The server distributes user input to, and accepts
output requests from, various client programs through a
variety of different interprocess communication channels.
Although the most common case is for the client programs to
be running on the same machine as the server, clients can
run transparently from other machines (including machines
with different architectures and operating systems).
X supports overlapping hierarchical subwindows and text and
graphics operations on both monochrome and color displays.
The number of programs that use X is growing rapidly. Of
particular interest are: a terminal emulator (xterm), a
window manager (mwm), a display manager (xdm), mail managing
utilities (xbiff), a manual page browser (xman), a bitmap
editor (bitmap), an access control program (xhost), user
preference setting programs (xrdb, xset, xsetroot, and
Page 1 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
xmodmap), a load monitor (xload), clock (xclock), a font
displayer (xfd), utilities for listing information about
fonts, windows, and displays (xlsfonts, xlswins, xwininfo,
xdpyinfo, and xprop), a diagnostic for seeing what events
are generated and when (xev), screen image manipulation
utilities (xwd, xwud, xpr, and xmag), and various demos
(xeyes, ico, etc.).
Many other utilities, window managers, games, toolkits, and
more are available from the user-contributed distribution.
See your site administrator for details.
STARTING UP
There are three ways to start the X server and an initial
set of client applications. The method you should use
depends on what operating system you are running and whether
or not you use other window systems in addition to X.
xdm (the X Display Manager)
If you always want X running on your display, your site
administrator can set up your machine to use the X
Display Manager xdm. This program is typically started
by the system at boot time and takes care of keeping
the server running and getting users logged in. If you
run xdm, you see a window on the screen welcoming you
to the system and asking for your user name and
password. Simply type them in as you would at a normal
terminal and press Enter after each. If you make a
mistake, xdm displays an error message and asks you to
try again. After you successfully log in, xdm starts
up your X environment. By default, if you have an
executable file named .xsession in your home directory,
xdm runs it to start up your initial clients (such as
terminal emulators, clocks, a window manager, user
settings for things like the background, the speed of
the mouse, etc.). Your site administrator can provide
details.
xterm -L (started from /etc/init)
If you are using a version of UNIX derived from 4.3
BSD, you can start the window system and an initial
xterm window from the system terminal line
configuration file, /etc/ttys. As with xdm, a window
appears that requests your user name and password.
However, this window becomes your primary window and it
is not configurable on a per-user basis. Sites that
use this method should switch to xdm as xterm -L is not
supported in this release.
xinit (run manually from the shell)
Sites that support more than one window system can use
the xinit program for starting X manually. Your site
Page 2 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
administrator can provide a program named x11, startx,
or xstart that initializes site-specific activities,
such as loading convenient default resources, running a
window manager, displaying a clock, and starting
several terminal emulators. You can also build such a
script using the xinit program. This utility simply
runs one user-specified program to start the server,
runs another to start up any desired clients, and then
waits for either to finish. Since either or both of
the user-specified programs may be a shell script, this
gives substantial flexibility at the expense of a nice
interface. For this reason, xinit is not intended for
end users.
DISPLAY NAMES
From the user's perspective, every X server has a display
name of the form:
hostname:displaynumber.screennumber
The application uses this information to determine how it
should connect to the server and which screen it should use
by default (on displays with multiple monitors). This
information is explained below:
hostname
Specifies the name of the machine to which the display
is physically connected. If the host name is not
given, the most efficient way available to communicate
to a server on the same machine is used.
displaynumber
The phrase "display" is usually used to refer to
collections of monitors that share a common keyboard
and mouse. Most workstations tend to have only one
keyboard, and therefore, only one display. Larger,
multiuser systems, however, frequently have several
displays so that more than one person can be doing
graphics work simultaneously. To avoid confusion, each
display on a machine is assigned a display number
(beginning at 0) when the X server for that display is
started. The display number must always be given in a
display name.
screennumber
Some displays share a single keyboard and mouse among
two or more monitors. Since each monitor has its own
set of windows, each screen is assigned a screen number
(beginning at 0) when the X server for that display is
started. If the screen number is not given, then
screen 0 will be used.
Page 3 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
On UNIX systems, the default display name is stored in your
DISPLAY environment variable. This variable is set
automatically by the xterm terminal emulator. However, when
you log into another machine on a network, you'll need to
set DISPLAY manually to point to your display. For example,
% setenv DISPLAY myws:0
$ DISPLAY=myws:0; export DISPLAY
Finally, most X programs accept a command-line option of
-display displayname to temporarily override the contents of
DISPLAY. You would use this option most commonly to pop
windows on another person's screen or as part of a "remote
shell" command to start an xterm session pointing back to
your display. For example:
% xeyes -display joesws:0 -geometry 1000x1000+0+0
% rsh big xterm -display myws:0 -ls </dev/null &
X servers listen for connections on a variety of different
communications channels (network byte streams, etc.). Since
there can be more than one way of contacting a given server,
The hostname part of the display name determines the type of
channel (also called a transport layer) to use.
X servers support the following types of connections:
TCP/IP
The hostname part of the display name should be the
server machine's IP address name. Full Internet names,
abbreviated names, and IP addresses are all allowed.
For example: expo.lcs.mit.edu:0, expo:0,
18.30.0.212:0, bigmachine:1, and hydra:0.1.
GEOMETRY SPECIFICATIONS
One of the advantages of using window systems instead of
hard-wired terminals is that applications don't have to be
restricted to a particular size or location on the screen.
Although the layout of windows on a display is controlled by
the window manager you are running (described below), most X
programs accept a command-line argument of the form
-geometry WIDTHxHEIGHT+XOFF+YOFF (where WIDTH, HEIGHT, XOFF,
and YOFF are numbers) for specifying a preferred size and
location for this application's main window.
The WIDTH and HEIGHT parts of the geometry specification are
usually measured in either pixels or characters, depending
on the application. The XOFF and YOFF parts are measured in
pixels and are used to specify the distance of the window
from the left or right and top or bottom edges of the
screen, respectively. Both types of offsets are measured
from the indicated edge of the screen to the corresponding
Page 4 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
edge of the window. You can specify the X offset in the
following ways:
+XOFF
Places the left edge of the window XOFF pixels in from
the left edge of the screen (i.e. the X coordinate of
the window's origin is XOFF). XOFF can be negative, in
which case the left edge of the window is off the
screen.
-XOFF
Places the right edge of the window XOFF pixels in from
the right edge of the screen. XOFF can be negative, in
which case the right edge of the window is off the
screen.
The Y offset has similar meanings:
+YOFF
Places the top edge of the window YOFF pixels below the
top edge of the screen (i.e. the Y coordinate of the
window's origin is YOFF). YOFF can be negative, in
which case the top edge of the window is off the
screen.
-YOFF
Places the bottom edge of the window YOFF pixels above
the bottom edge of the screen. YOFF can be negative,
in which case the bottom edge of the window appears off
the screen.
Offsets must be given as pairs; in other words, in order to
specify either XOFF or YOFF both must be present. You can
place windows in the four corners of the screen using the
following specifications:
+0+0 Upper left-hand corner.
-0+0 Upper right-hand corner.
-0-0 Lower right-hand corner.
+0-0 Lower left-hand corner.
In the following examples, a terminal emulator is placed in
roughly the center of the screen and a load average monitor,
mailbox, and clock is placed in the upper right-hand corner:
xterm -fn 6x10 -geometry 80x24+30+200 &
xclock -geometry 48x48-0+0 &
xload -geometry 48x48-96+0 &
xbiff -geometry 48x48-48+0 &
Page 5 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
WINDOW MANAGERS
The layout of windows on the screen is controlled by special
programs called window managers. Although many window
managers will honor geometry specifications as given, others
may choose to ignore them (requiring you to explicitly draw
the window's region on the screen with the mouse, for
example).
Since window managers are regular (albeit complex) client
programs, you can build a variety of different user
interfaces.
FONT NAMES
Collections of characters that display text and symbols in X
are known as fonts. A font typically contains images that
share a common appearance and look nice together (for
example, a single size, boldness, slant, and character set).
Similarly, collections of fonts that are based on a common
type face (the variations are usually called roman, bold,
italic, bold italic, oblique, and bold oblique) are called
families.
Sets of font families of the same resolution (usually
measured in dots per inch) are further grouped into
directories (so named because they were initially stored in
file-system directories). Each directory contains a
database that lists the font name and information on how to
find the font. The server uses these databases to translate
font names (which have nothing to do with file names) into
font data.
The font path controls the list of font directories where
the server looks when trying to find a font. Although most
installations choose to have the server start with all of
the commonly used font directories, you can change the font
path any time with the xset program. However, it is
important to remember that the directory names are on the
server's machine, not on the application's.
The default font path for the sample server contains three
directories:
/usr/lib/X11/fonts/misc
Contains several miscellaneous fonts that are useful on
all systems. It contains a very small family of
fixed-width fonts (6x10, 6x12, 6x13, 8x13, 8x13bold,
and 9x15) and the cursor font. It also has font name
aliases for the commonly used fonts fixed and variable.
/usr/lib/X11/fonts/75dpi
Contains fonts contributed by Adobe Systems, Inc.,
Digital Equipment Corporation, and Bitstream, Inc. for
Page 6 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
75-dots-per-inch displays. An integrated selection of
sizes, styles, and weights is provided for each family.
/usr/lib/X11/fonts/100dpi
Contains 100-dots-per-inch versions of some of the
fonts in the 75dpi directory.
You create font databases by running the mkfontdir program
in the directory containing the source or compiled versions
of the fonts (in both compressed and uncompressed formats).
Whenever you add fonts to a directory, you should rerun
mkfontdir so the server can find the new fonts. To make the
server reread the font database, reset the font path with
the xset program. For example, to add a font to a private
directory, you could use the following commands:
% cp newfont.snf ~/myfonts
% mkfontdir ~/myfonts
% xset fp rehash
You can use the xlsfonts program to list all of the fonts
that are found in font databases in the current font path.
Font names tend to be fairly long as they contain all of the
information needed to uniquely identify individual fonts.
However, the sample server allows you to specify font names
with wildcard characters, so the full specification:
-adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1
could be abbreviated as:
*-courier-medium-r-normal--*-100-*
Because the shell also has special meanings for * and ?,
font names using wildcards should be quoted:
% xlsfonts -fn '*-courier-medium-r-normal--*-100-*'
If more than one font in the font path matches a font name
specified with wildcards, the server chooses which font to
return. However, if fonts from more than one directory
match a name, the returned font is always from the first
such directory in the font path. The example given above
matches fonts in both the 75dpi and 100dpi directories; if
the 75dpi directory is ahead of the 100dpi directory in the
font path, the smaller version of the font is used.
COLOR NAMES
Most applications allow you to choose (usually through
resources or command-line arguments) the colors for the text
and graphics in your windows. Although black and white
Page 7 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
displays don't provide much of a choice, color displays
frequently allow anywhere between 16 and 16 million
different colors.
You usually specify colors by their commonly-used names (for
example, red, white, or medium slate blue). The server
translates these names into appropriate screen colors using
a color database usually found in /usr/lib/X11/rgb.txt.
Color names are case-insensitive, meaning that red, Red, and
RED all refer to the same color.
Many applications also accept color specifications of the
following form:
#rgb
#rrggbb
#rrrgggbbb
#rrrrggggbbbb
where r, g, and b are hexidecimal numbers indicating how
much red, green, and blue should be displayed (0 being none
and ffff being on full). Each field specified must have the
same number of digits (e.g., #rrgb or #gbb are not allowed).
Fields that have fewer than four digits (e.g. #rgb) are
padded out with 0s following each digit (e.g.
#r000g000b000). The eight primary colors can be represented
as follows:
black #000000000000 (no color at all)
red #ffff00000000
green #0000ffff0000
blue #00000000ffff
yellow #ffffffff0000 (full red and green, no blue)
magenta #ffff0000ffff
cyan #0000ffffffff
white #ffffffffffff (full red, green, and blue)
Unfortunately, RGB color specifications are highly
unportable since different monitors produce different shades
when given the same inputs. Similarly, color names aren't
portable because there is no standard naming scheme and the
color database needs to be tuned for each monitor.
Application developers should take care to make their colors
portable.
KEYS
The X keyboard model is broken into two layers: server-
specific codes (called keycodes) which represent the
physical keys, and server-independent symbols (called
keysyms) which represent the letters or words that appear on
the keys. Two tables are kept in the server for converting
Page 8 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
keycodes to keysyms:
modifier list
Some keys (such as Shift, Control, and Caps Lock) are
known as modifier keys and are used to select different
symbols that are attached to a single key. For
example, Shift-A generates a capital A, and Control-l
generates a form-feed character ^L). The server keeps
a list of keycodes corresponding to the various
modifier keys. Whenever a key is pressed or released,
the server generates an event that contains the keycode
of the indicated key as well as a mask that specifies
which of the modifier keys are currently pressed. Most
servers set up this list to initially contain the
various Shift, Control, and Shift Lock keys on the
keyboard.
keymap table
Applications translate event keycodes and modifier
masks into keysyms using a keysym table which contains
one row for each keycode and one column for each
modifier. The server initializes this table to
correspond to normal typewriter conventions, but it is
only used by client programs.
Although most programs deal with keysyms directly (such as
those written with the X Toolkit), most programming
libraries provide routines for converting keysyms into the
appropriate type of string (such as ISO Latin-1). However,
programs that use such routines are usually not as flexible.
OPTIONS
Most X programs attempt to use the same names for command
line options and arguments. All applications written with
the X Toolkit automatically accept the options described
below.
-display display
Specifies the name of the X server.
-geometry geometry
Specifies the initial size and location of the window.
-bg color, -background color
Either option specifies the color for the window
background.
-bd color, -bordercolor color
Either option specifies the color for the window
border.
-bw number, -borderwidth number
Page 9 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
Either option specifies the width of the window border
in pixels.
-fg color, -foreground color
Either option specifies the color for text or graphics.
-fn font, -font font
Either option specifies the font for displaying text.
-iconic
Starts the application in an iconic state. Some window
managers may not honor the application's request.
-name
Specifies the name under which resources for the
application should be found. This option is useful in
shell aliases to distinguish between invocations of an
application without resorting to creating links to
alter the executable file name.
-rv, -reverse
Either option requests the program to simulate reverse
video by swapping the foreground and background colors.
Not all programs honor this or implement it correctly.
It is usually used on monochrome displays.
-synchronous
Sends requests to the X server synchronously, instead
of asynchronously. Since Xlib normally buffers
requests to the server, errors do not get reported
immediately after they occur. This option turns off
the buffering so that you can debug the application.
You should never use this option with a working
program.
-title string
Specifies the title for this window. The window
manager can use this information to provide a header
that identifies the window.
-xrm resourcestring
Specifies a resource name and value to override any
defaults. It is also very useful for setting resources
that don't have explicit command-line arguments.
RESOURCES
You can tailor applications to your personal preferences
because X supports several mechanisms for storing default
values for program resources (e.g. background color, window
title, etc.)
Resources are specified as strings of the form
Page 10 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
name*subname*subsubname...: value that are read in from
various places when an application starts up. The Xlib
routine XGetDefault(3X) and the resource utilities within
the X Toolkit obtain resources from the following sources:
RESOURCEMANAGER root window property
Any global resources that should be available to
clients on all computers should be stored in the
RESOURCE_MANAGER property on the root window using the
xrdb program. If you start up X through the display
manager or with xinit, this can happen automatically.
application-specific files
Any application- or machine-specific resources can be
stored in the class resource files located in the
XAPPLOADDIR directory (this is a configuration
parameter that is /usr/lib/X11/app-defaults in the
standard distribution). Programs that use the X
Toolkit also look in the directory named by the
environment variable XAPPLRESDIR (the default value is
your home directory) for files named Class where Class
is the class name of the particular application. The
XAPPLOADDIR and XAPPLRESDIR configuration files are
actually loaded before the RESOURCE_MANAGER property,
so the property can override the values.
XENVIRONMENT
Any user- and machine-specific resources can be
specified by setting the XENVIRONMENT environment
variable to the name of a resource file to be loaded by
all applications. If you do not define this variable,
the X Toolkit looks for a file named .Xdefaults-
hostname, where hostname is the name of the host where
the application is executing.
-xrm resourcestring
Applications that use the X Toolkit can have resources
specified from the command line. The resourcestring is
a single resource name and value as shown above. Note
that if the string contains characters interpreted by
the shell (e.g., asterisk), they must be quoted. You
can specify any number of -xrm arguments on the command
line.
Program resources are organized into groups called classes,
so that collections of individual resources (each of which
are called instances) can be set all at once. By
convention, the instance name of a resource begins with a
lowercase letter and class name with an uppercase letter.
Multiple word resources are concatenated with the first
letter of the succeeding words capitalized. Applications
written with the X Toolkit have at least the following
Page 11 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
resources:
background (class Background)
Specifies the color for the window background.
borderWidth (class BorderWidth)
Specifies the width of the window border in pixels.
borderColor (class BorderColor)
Specifies the color for the window border.
Most X Toolkit applications also have the resource
foreground (class Foreground), specifying the color for text
and graphics within the window.
By combining class and instance specifications, you can set
application preferences quickly and easily. Users of color
displays frequently want to set Background and Foreground
classes to particular defaults. You can override specific
color instances such as text cursors without having to
define all of the related resources. For example:
bitmap*Dashed: off
XTerm*cursorColor: gold
XTerm*multiScroll: on
XTerm*jumpScroll: on
XTerm*reverseWrap: on
XTerm*curses: on
XTerm*Font: 6x10
XTerm*scrollBar: on
XTerm*scrollbar*thickness: 5
XTerm*multiClickTime: 500
XTerm*charClass: 33:48,37:48,45-47:48,64:48
XTerm*cutNewline: off
XTerm*cutToBeginningOfLine: off
XTerm*titeInhibit: on
XTerm*ttyModes: intr ^c erase ^? kill ^u
XLoad*Background: gold
XLoad*Foreground: red
XLoad*highlight: black
XLoad*borderWidth: 0
emacs*Geometry: 80x65-0-0
emacs*Background: #5b7686
emacs*Foreground: white
emacs*Cursor: white
emacs*BorderColor: white
emacs*Font: 6x10
xmag*geometry: -0-0
xmag*borderColor: white
mwm*bordercolor: black
mwm*Foreground: #f00
mwm*Background: #ede7e2
Page 12 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
mwm*borderwidth: 0
mwm*iborderwidth: 0
mwm*mborderwidth: 1
If you stored these resources in a file called .Xresources
in your home directory, you could add them to any existing
resources in the server with the following command:
% xrdb -merge $HOME/.Xresources
This is frequently how user-friendly start-up scripts merge
user-specific defaults into any site-wide defaults. All
sites are encouraged to set up convenient ways of
automatically loading resources.
EXAMPLES
The following is a collection of sample command lines for
some of the more frequently used commands. For more
information on a particular command, please refer to the
manual page for that command.
% xrdb -load $HOME/.Xresources
% xmodmap -e "keysym BackSpace = Delete"
% mkfontdir /usr/local/lib/X11/otherfonts
% xset fp+ /usr/local/lib/X11/otherfonts
% xmodmap $HOME/.keymap.km
% xsetroot -solid '#888'
% xset b 100 400 c 50 s 1800 r on
% xset q
% mwm
% xmag
% xclock -geometry 48x48-0+0 -bg blue -fg white
% xeyes -geometry 48x48-48+0
% xbiff -update 20
% xlsfonts '*helvetica*'
% xlswins -l
% xwininfo -root
% xdpyinfo -display joesworkstation:0
% xhost -joesworkstation
% xrefresh
% xwd | xwud
% bitmap companylogo.bm 32x32
% xcalc -bg blue -fg magenta
% xterm -geometry 80x66-0-0 -name myxterm $*
DIAGNOSTICS
Various programs generate a wide variety of error messages.
Various toolkits should provide a common mechanism for
locating error text so that it is easy to tailor
applications. Programs written to interface directly to the
Xlib C language library are expected to do their own error
Page 13 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
checking.
The default error handler in Xlib (also used by many
toolkits) uses standard resources to construct diagnostic
messages when errors occur. The defaults for these messages
are usually stored in /usr/lib/X11/XErrorDB. If this file
is not present, error messages are rather terse and cryptic.
When the X Toolkit encounters errors converting resource
strings to the appropriate internal format, no error
messages usually print. This is convenient when you want to
have one set of resources across a variety of displays (e.g.
color versus. monochrome, lots of fonts versus very few,
etc.), although it can pose problems when you need to
determine why an application is failing. You can override
this behavior by the setting the StringConversionsWarning
resource.
To force the Toolkit to always print string conversion error
messages, place the following resource at the top of the
file that gets loaded in to the RESOURCE_MANAGER property
using the xrdb program (frequently called .Xresources or
.Xres in your home directory):
*StringConversionWarnings: on
To have conversion messages printed for just a particular
application, place the appropriate instance name before the
asterisk:
xterm*StringConversionWarnings: on
BUGS
If you encounter a bug that you can re-create, please
contact your site administrator for instructions on how to
submit an X bug report.
SEE ALSO
Xsight(X), mkfontdir(X), bitmap(X), mwm(X), xbiff(X),
xcalc(X), xclock(X), xdpyinfo(X), xedit(X), xev(X), xfd(X),
xhost(X), xinit(X), xkill(X), xload(X), xlogo(X),
xlsfonts(X), xlswins(X), xmag(X), xman(X), xmodmap(X),
xpr(X), xprop(X), xrdb(X), xrefresh(X), xset(X),
xsetroot(X), resize(X), xterm(X), xwd(X), xwininfo(X),
xwud(X), bdftosnf(X), Xlib - C Language X Interface, X
Toolkit Intrinsics - C Language X Interface, and Using and
Specifying X Resources
COPYRIGHT
The following copyright and permission notice outlines the
rights and restrictions covering most parts of the standard
Page 14 (printed 7/3/90)
X(X) X Version 11 (11 July 1990) X(X)
distribution of the X Window System from MIT. Other parts
have additional or different copyrights and permissions; see
the individual source files.
Copyright 1984, 1985, 1986, 1987, 1988, Massachusetts
Institute of Technology.
Permission to use, copy, modify, and distribute this
software and its documentation for any purpose and without
fee is hereby granted, provided that the above copyright
notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting
documentation, and that the name of M.I.T. not be used in
advertising or publicity pertaining to distribution of the
software without specific, written prior permission. M.I.T.
makes no representations about the suitability of this
software for any purpose. It is provided "as is" without
express or implied warranty.
This software is not subject to any license of the American
Telephone and Telegraph Company or of the Regents of the
University of California.
AUTHORS
A cast of thousands. See the file doc/contributors in the
standard sources for some of the names.
Page 15 (printed 7/3/90)