X(1) X(1)
NAME
X - a portable, network-transparent window system
SYNOPSIS
Graphic Services Extension (GSE) is Motorola's
implementation of the X Window System. X is a
network-transparent window system developed at MIT that
runs on a wide range of computing and graphics
machines.
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
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 interprocess communication
channels. Although the most common case is for the
client programs to run on the same machine as the
server, clients can be run transparently from other
machines (including machines with different
architectures and operating systems) as well.
X supports overlapping hierarchical subwindows and text
and graphics operations, on both monochrome and color
displays.
A wide variety of application programs use X. See the
DeltaWINDOWS Product Guide for more information about
these programs and references to other documents.
STARTING UP
Before you can use X applications, the X server and an
initial client process must have been started. See
your site administrator for details. If you want to
always have X running on your display, your site
administrator can set your machine up 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.
- 1 -
X(1) X(1)
If you are running xdm, you will see a window on the
screen welcoming you to the system and asking for your
username and password. Type them in as you would at a
normal terminal, pressing the <RETURN> key after each.
If you make a mistake, xdm will display an error
message and ask you to try again. After you have
successfully logged in, xdm will start up your X
environment. By default, if you have an executable
file named .xsession in your home directory, xdm will
treat it as a program (or shell script) for starting up
your initial clients (such as terminal emulators,
clocks, a window manager, user settings for things like
the background, the speed of the pointer, etc.). Your
site administrator can provide details.
DISPLAY NAMES
From the user's perspective, every X server has a
display name of the form:
hostname:displaynumber.screennumber
This information is used by the application to
determine how it should connect to the server and which
screen it should use by default (on displays with
multiple monitors), as follows:
hostname
This part of the display name specifies the
hostname of the machine to which the display is
physically connected. If the host name is not
given, the most efficient way of communicating to a
server on the same machine will be used.
displaynumber
The term display usually refers to a collection of
monitors that share a common keyboard and pointer
(e.g., mouse, tablet). Some systems have only one
keyboard and, therefore, only one display.
Multiuser systems may have several displays so that
more than one person can be doing graphics work at
once. 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 part of a display
name.
screennumber
Some displays share a single keyboard and pointer
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
- 2 -
X(1) X(1)
is not given, screen 0 will be used.
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 in to another machine on a network, you'll
need to set DISPLAY by hand to point to your display.
For example:
DISPLAY=myws:0; export DISPLAY
vs 12
Finally, most X programs accept a command line option
of -display displayname to temporarily override the
contents of DISPLAY. This is most commonly used to pop
windows on another person's screen or as part of a
remote shell command to start an xterm pointing back to
your display. For example:
xeyes -display joesws:0 -geometry 1000x1000+0+0
remsh myhost /bin/X11/xterm -display myws:0 -ls </dev/null &
X servers listen for connections on a variety of
communications channels (e.g., network byte streams,
shared memory). Since there can be more than one way
of contacting a given server, the host name part of the
display name is used to determine the type of channel
(also called a transport layer) to be used. The GSE X
server supports the following types of connections:
TCP/IP
The host name 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. Example include:
expo.lcs.mit.edu:0, expo:0, 18.30.0.212:0,
bigmachine:1, and hydra:0.1.
System V Streams
The host name part of the display name should be
empty. Examples include: :0, :1, and :0.1. This
is a different implementation of System V Streams
connections from that in X11R4 from MIT.
GEOMETRY SPECIFICATIONS
One of the advantages of using window systems instead
of hardwired terminals is that applications do not 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 the user is
running (described below), most X programs accept a
command line argument of the form -geometry
- 3 -
X(1) X(1)
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 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 the top or bottom edges of the screen,
respectively. Both types of offsets are measured from
the indicated edge of the screen to the corresponding
edge of the window. The X offset may be specified in
the following ways:
+XOFF
The left edge of the window is to be placed XOFF
pixels in from the left edge of the screen (i.e.,
the X coordinate of the window's origin will be
XOFF). XOFF may be negative, in which case the
window's left edge will be off the screen.
-XOFF
The right edge of the window is to be placed XOFF
pixels in from the right edge of the screen. XOFF
may be negative, in which case the window's right
edge will be off the screen.
The Y offset has similar meanings:
+YOFF
The top edge of the window is to be YOFF pixels
below the top edge of the screen (i.e., the Y
coordinate of the window's origin will be YOFF).
YOFF may be negative, in which case the window's
top edge will be off the screen.
-YOFF
The bottom edge of the window is to be YOFF pixels
above the bottom edge of the screen. YOFF may be
negative, in which case the window's bottom edge
will be off the screen.
Offsets must be given as pairs; in other words, to
specify either XOFF or YOFF both must be present.
Windows can be placed 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
- 4 -
X(1) X(1)
In the following examples, a terminal emulator will be
placed in roughly the center of the screen, and a load
average monitor, mailbox, and clock will be 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 &
It is possible to combine the positive and negative
signs to control the geometry. For example, the
following command attempts to place the right edge of
the window at a location that is 100 pixels in from the
right side of the screen and the top edge 50 pixels
down from the top of the screen:
xterm -geometry 80x24--100+-50 &
These examples normally place the windows at the
expected locations if you are running the uwm window
manager. But some window managers, such as twm and mwm
(see the following discussion of window managers), may
override geometry requests and place windows at a
location that only approximates the requested position.
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 the
user to explicitly draw the window's region on the
screen with the pointer, for example).
Since window managers are regular, albeit complex,
client programs, a variety of user interfaces can be
built. GSE comes with a window manager called uwm that
supports overlapping windows, popup menus, point-and-
click or click-to-type input models, and minimal use of
screen real estate (it does not provide title bars
around windows). It tries to stay out of the way as
much as possible but can be somewhat difficult to
master.
Other window managers that are available:
twm
This window manager provides title bars, resize and
reposition boxes, and specially designed icons. It
is known for its small size and simplicity. twm is
an unsupported client that is provided in the GSE
demos directory.
- 5 -
X(1) X(1)
mwm
This is the Motif window manager from The Open
Software Foundation. mwm is available on the
Motorola Motif installation tape.
FONT NAMES
Collections of characters for displaying 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 typeface are called
families; the variations within a family are usually
roman, bold, italic, bold italic, oblique, and bold
oblique.
Sets of font families of the same resolution, usually
measured in dots per inch (dpi), are further grouped
into directories (so named because they were initially
stored in file system directories). Each directory
contains a database that lists the name of the font 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 list of font directories in which the server looks
when trying to find a font is controlled by the font
path. Although most installations will choose to have
the server start up with the commonly used font
directories, the font path can be changed at 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. If your display is
an X terminal, see the X terminal documentation for
information about font availability.
The default font path for the GSE X server contains
three directories:
/usr/lib/X11/fonts/misc
This directory contains several miscellaneous fonts
that are useful on all systems. It contains a very
small family of fixed-width fonts (6x10, 6x12,
6x13, 8x13, 8x13B (bold), 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
This directory contains fonts contributed by Adobe
Systems, Inc. and Digital Equipment Corporation and
by Bitstream, Inc. for 75 dpi displays. An
integrated selection of sizes, styles, and weights
- 6 -
X(1) X(1)
are provided for each family.
/usr/lib/X11/fonts/100dpi
This directory contains 100 dpi versions of some of
the fonts in the 75dpi directory.
If you have an NCD X terminal, the corresponding font
paths are:
/usr/lib/X11/ncd/fonts/misc
/usr/lib/X11/ncd/fonts/75dpi
/usr/lib/X11/ncd/fonts/100dpi
Font databases are created by running the mkfontdir
program in the directory containing the source or
compiled versions of the fonts (in both compressed and
uncompressed formats). Whenever fonts are added to a
directory, rerun mkfontdir so that 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, the following commands could be used to
add a font to a private directory:
cp newfont.snf /myfonts
~
mkfontdir /myfonts
~
xset fp rehash
The xlsfonts program can be used to list all the fonts
that are found in the font databases in the current
font path. Font names tend to be long because they
contain all the information needed to uniquely identify
individual fonts. However, the X server supports
wildcarding of font names, 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
?, wildcarded font names should be quoted:
xlsfonts -fn '*-courier-medium-r-normal--*-100-*'
If more than one font in a given directory in the font
path matches a wildcarded font name, the choice of
which font to return is left to the server. 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
- 7 -
X(1) X(1)
fonts in both the 75dpi and 100dpi directories; if the
75dpi directory is ahead of the 100dpi directory in the
font path, the 75dpi version is used.
COLOR NAMES
Most applications provide ways of tailoring the colors
of various elements in the text and graphics they
display. This is usually done through resources or
command line arguments. Although black and white
displays do not provide much of a choice, color
displays frequently allow between 16 and 16 million
colors.
Colors are usually specified by their commonly used
names, e.g., red, white, or medium slate blue. The
server translates these names into appropriate screen
colors using a color database that is found in
/usr/lib/X11/rgb (for MVME393/395 X servers) or
/usr/lib/X11/ncd/rgb.txt (for X terminals). Color
names are case-insensitive, meaning that red, Red, and
RED all refer to the same color. In addition,
separating spaces in color names are ignored. For
example, Medium Slate Blue is equivalent to
mediumslateblue.
Many applications also accept color specifications of
the following form:
#rgb
#rrggbb
#rrrgggbbb
#rrrrggggbbbb
where r, g, and b are hexadecimal numbers indicating
how much red, green, and blue should be displayed, zero
being none and ffff being full. Each field in the
specification 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 zeros following each digit (e.g., #r000g000b000).
The eight primary colors can be represented like this:
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)
- 8 -
X(1) X(1)
Unfortunately, RGB color specifications are highly
unportable, since different monitors produce different
shades given the same inputs. Similarly, color names
are not 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 tailorable.
KEYS
The X keyboard model contains of two layers: server-
specific codes (called keycodes) which represent the
physical keys, and server-independent symbols (called
keysyms) that represent the letters or words that
appear on the keys. The server keeps two tables for
converting keycodes to keysyms:
modifier list
Some keys (such as <SHIFT>, <CTRL>, and <CAPS
LOCK>) are known as modifiers and are used to
select different symbols that are attached to a
single key. For example, <SHIFT-a> generates a
capital A, and <CTRL-l> generates a formfeed
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 initially
set this list to contain the various <SHIFT>,
<CTRL>, 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. This table is initialized by
the server to correspond to normal typewriter
conventions, but it is only used by client
programs.
Most programs, such as those written with the X
Toolkit, deal with keysyms directly. Most programming
libraries provide routines for converting keysyms into
the appropriate type of string (e.g., ISO Latin-1), but
programs that use such routines are usually less
portable and less flexible.
OPTIONS
- 9 -
X(1) X(1)
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
following options:
-display display
specifies the name of the X server to use.
-geometry geometry
specifies the initial size and location of the
window.
-bg color, -background color
either option specifies the color to use for the
window background.
-bd color, -bordercolor color
either option specifies the color to use for the
window border.
-bw number, -borderwidth number
either option specifies the width in pixels of the
window border.
-fg color, -foreground color
either option specifies the color to use for text
or graphics.
-fn font, -font font
either option specifies the font to use for
displaying text.
-iconic
indicates that the application's windows initially
not be visible, as if the windows had to be
immediately iconified by the user. Window managers
may choose not to 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 filename.
-rv, -reverse
indicates that the program should simulate reverse
video if possible, often by swapping the foreground
and background colors. Not all programs honor this
or implement it correctly; it is usually only used
on monochrome displays.
- 10 -
X(1) X(1)
+rv
indicates that the program should not simulate
reverse video. This is used to override any
defaults since reverse video does not always work
properly.
-synchronous
indicates that requests to the X server should be
sent synchronously instead of asynchronously.
Since the X library (Xlib) normally buffers
requests to the server, errors do not necessarily
get reported immediately after they occur. This
option turns off the buffering so that the
application can be debugged; it should never be
used with a working program.
-title string
specifies the title to be used for this window.
This information is sometimes used by a window
manager to provide a header identifying the window.
-xrm resourcestring
specifies a resource name and value to override any
defaults. It is also very useful for setting
resources that do not have explicit command line
arguments.
RESOURCES
To make the tailoring of applications to personal
preferences easier, X supports several mechanisms for
storing default values for program resources (e.g.,
background color, window title). Resources are
specified as strings of this form:
name*subname*subsubname...: value
These strings are read in from various places when an
application is run. 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 machines should be stored in the
RESOURCE_MANAGER property on the root window using
the xrdb program. This is frequently taken care of
when the user starts up X through the display
manager.
- 11 -
X(1) X(1)
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 by
default). Programs that use the X Toolkit also
look in the directory named by the environment
variable XAPPLRESDIR (default value is user's home
directory) for files named Class where Class is the
class name of the particular application.
XAPPLOADDIR and XAPPLRESDIR configuration files are
loaded before the RESOURCE_MANAGER property so that
the property can override the values.
XENVIRONMENT
Any user- and machine-specific resources may be
specified by setting the XENVIRONMENT environment
variable to the name of a resource file to be
loaded by all applications. If this variable is
not defined, the X Toolkit looks for a file named
.Xdefaults-hostname, where hostname is the name of
the host where the application is executing.
-xrm resource string
Applications that use the X Toolkit can have
resources specified from the command line. The
resource string 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. Any number of
these arguments may be given on the command line.
Program resources are organized into groups called
classes, so that collections of individual resources
(each of which is called an instance) can be set all at
once. By convention, the instance name of a resource
begins with a lowercase letter and the 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 will have at least the following resources:
background (class Background)
specifies the color to use for the window
background.
borderWidth (class BorderWidth)
specifies the width in pixels of the window border.
borderColor (class BorderColor)
specifies the color to use for the window border.
- 12 -
X(1) X(1)
Most X Toolkit applications also have the resource
foreground (class Foreground), specifying the color to
use for text and graphics within the window.
By combining class and instance specifications,
application preferences can be set quickly and easily.
Users of color displays will frequently want to set
Background and Foreground classes to particular
defaults. Specific color instances, such as text
cursors, can then be overridden 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
uwm*bordercolor: black
uwm*Foreground: #f00
uwm*Background: #ede7e2
uwm*borderwidth: 0
uwm*iborderwidth: 0
uwm*mborderwidth: 1
- 13 -
X(1) X(1)
If these resources were stored in a file called
.Xresources in your home directory, they could be added
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, refer to that
command's manual page.
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
uwm
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
A wide variety of error messages are generated from
various programs. Toolkits are encouraged to provide a
common mechanism for locating error text. Programs
written to interface directly to the Xlib C language
library are expected to do their own error checking.
- 14 -
X(1) X(1)
The default error handler in Xlib, which is 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 will be terse and cryptic.
When the X Toolkit encounters errors converting
resource strings to the appropriate internal format,
error messages are not usually printed. This is
convenient when it is desirable to have one set of
resources across a variety of displays (e.g., color vs.
monochrome, many fonts vs. few), although it can pose
problems when trying to determine why an application
might be failing. This behavior can be overridden by
setting the StringConversionWarnings 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 onto the RESOURCE_MANAGER
property using the xrdb program (this file is
frequently called .Xresources, .Xres, or .Xdefaults in
the user's home directory):
*StringConversionWarnings: on
To have conversion messages printed for a particular
application, the appropriate instance name can be
placed before the asterisk:
xterm*StringConversionWarnings: on
SEE ALSO
mkfontdir(1), bitmap(1), uwm(1), xbiff(1), xcalc(1),
xclock(1), xdpyinfo(1), xedit(1), xev(1), xfd(1),
xhost(1), xkill(1), xload(1), xlogo(1), xlsfonts(1),
xlswins(1), xmag(1), xman(1), xmh(1), xmodmap(1),
xpr(1), xprop(1), xrdb(1), xrefresh(1), xset(1),
xsetroot(1), xterm(1), xwd(1), xwininfo(1), xwud(1),
bdftosnf(1)
Graphic Services Extension Software Release Guide
DeltaWINDOWS Product Guide
- 15 -