Xdec(1X)Xdec(1X)NAME
Xdec, Xserver - X Window System server
SYNOPSIS
Xdec [-option...]
OPTIONS
The X server accepts the following command line options: Sets pointer
acceleration (that is, the ratio of how much is reported to how much
the user actually moved the pointer). Disables host-based access con‐
trol mechanisms. Enables access by any host, and permits any host to
modify the access control list. Use with extreme caution. This option
exists primarily for running test suites remotely. Sets the audit
trail level. The default level is 1, meaning only connection rejec‐
tions are reported. Level 2 additionally reports all successful con‐
nections and disconnections. Level 0 turns off the audit trail. Audit
lines are sent as standard error output. Sets the XKB autorepeat delay
to the specified number. The delay number can be a range of 0-1000.
Sets the XKB autorepeat delay to the specified number. The interval
number can be a range of 0-1000. Specifies a file which contains a
collection of authorization records used to authenticate access. See
also the xdm(1X) and Xsecurity(1X) manual pages. Disables certain
kinds of error checking, for bug compatibility with previous releases
(for example, to work around bugs in R2 and R3 xterms and toolkits).
Use of this option is not recommended. Disables backing store support
on all screens. Turns off key-click. Sets the key-click volume
(allowable range: 0-100). Sets the visual class for the root window of
color screens. The class numbers are those specified in the X proto‐
col. This option is not obeyed by all servers. Sets the name of the
RGB color database. Causes the server to generate a core dump on fatal
errors. Defines the number of cache units. The minimum (and also
default) value is 1024. If you specify a value lower than 1024, font
caching is disabled. For an ideographic language, the recommended
value is the lowest multiple of 1024 that accommodates the number of
frequently used characters in that language.
If a workstation displays multiple ideographic languages simul‐
taneously, you have to add together the values required for each
language. Specify an even larger value if you intend to run
applications, such as desktop publishing software, that require
multiple font styles and sizes for each ideographic character.
For more details, see Writing Software for the International
Market. Defines the size of each cache unit. The minimum value
for unit size is 31 bytes; the default value is 128 bytes. If
you specify a value lower than 31 bytes, the value has no
effect. If a particular font requires more memory space than
128 bytes, the font-cache mechanism automatically allocates one
or more additional units to store its glyphs. For more details,
see Writing Software for the International Market. Defere load‐
ing of no, all, or 16-nit glyphs. Enables the VESA Display
Power Management Signalling (DPMS) features of the X Server
regardless of the operating system's power management state.
DPMS mode defaults are dictated by the kernel's power management
subsystem. DPMS should only be enabled for systems with DPMS-
compliant hardware. Disables the VESA DPMS features of the X
Server regardless of the operating system's power management
state. DPMS mode defaults are dictated by the kernel's power
management subsystem. Sets the bell volume (allowable range:
0-100). Sets the default cursor font. Sets the default font.
Sets the search path for fonts. This path is a comma separated
list of directories which the X server searches for font data‐
bases. All components of the list must be valid font directories
or the X server will exit, not finding the default font.
It is recommended that you not use this option because of the
problems caused by an invalid font path. If you install a new
set of fonts, it is best to specify the font path in a start-up
file such as Xsession or using the xset +fp command. Then, if
the font path is invalid for any reason, the X server will still
run. Specifies the name of a configuration file that defines
the code sets and character associations for glyph caching when
the X server reads fonts from a font server. The default cache-
config file is /usr/var/X11/fs/fs_cache_config. If this config‐
uration file is defined or if the default fs_cache_config file
exists, glyph caching will be enabled when the X server is read‐
ing from a font server for those fonts whose code sets are spec‐
ified in the file. Prints a usage message. Causes all remain‐
ing command line arguments to be ignored. Enables use of the
lowbandwidth extension of the X server. The Low Bandwidth X
(LBX) extension defines compression and local caching techniques
that improve performance of X applications in wide area networks
and across slow speed network connections. Disables use of the
lowbandwidth extension of the X server. Sets the data space
limit of the server to the specified number of kilobytes. A
value of zero makes the data size as large as possible. The
default value of -1 leaves the data space limit unchanged. Sets
the number-of-open-files limit of the server to the specified
number. A value is zero makes the limit as large as possible.
The default value of -1 leaves the limit unchanged. Sets the
stack space limit of the server to the specified number of kilo‐
bytes. A value of zero makes the stack size as large as possi‐
ble. The default value of -1 leaves the stack space limit
unchanged. Turns on the X Window System logo display in the
screen-saver. There is currently no way to change this setting
from a client. Turns off the X Window System logo display in
the screen-saver. There is currently no way to change this set‐
ting from a client. Runs the Xserver at the specified schedul‐
ing priority. The priority argument is a positive or negative
decimal integer. Positive priority can range from 1 to 19,
where 19 is the lowest priority value. You must have superuser
authority to specify a negative priority value. Negative values
range from -1 to -12, where -12 is the highest scheduling prior‐
ity. Uses the DIGITAL UNIX vendor string, rather than the Tru64
UNIX vendor string. Sets the screen-saver pattern cycle time in
minutes. Enables the panoramiX extension which allows a system
with multiple video monitors to operate the monitors as a single
large screen. Disables the panoramiX extension. Turns off
auto-repeat. Turns on auto-repeat. Sets the screen-saver time‐
out time in minutes. Enable object reuse. Disable object re‐
use. Specifies the file that defines the security policy. Dis‐
ables the save under support on all screens. Sets the pointer
acceleration threshold in pixels (that is, after how many pixels
pointer acceleration should take effect). Causes the server to
terminate at server reset, instead of continuing to run. Sets
the default connection timeout in seconds. Disables all testing
extensions (for example, XTEST, XTrap, XTestExtension1). Sets
video-off screen-saver preference. Sets video-on screen-saver
preference. Forces the default backing-store of all windows to
be WhenMapped. This option is a quick way of getting backing-
store to apply to all windows. Loads the specified extension at
initialization. Some extensions have only a small portion loaded
at initialization, saving memory until the extension is actually
requested. This option forces the complete loading of the exten‐
sion at initialization time, saving a small amount of startup
time when the first request for the extension is made by a
client application. Not all extensions will implement this fea‐
ture. Specifies the directory that contains the Xprint server
configuration files.
You can also have the X server connect to xdm using XDMCP. Although
this method is not typically useful as it does not allow xdm to manage
the server process, it can be used to debug XDMCP implementations, and
serves as a sample implementation of the server side of XDMCP. For
more information on this protocol, see the X Display Manager Control
Protocol specification. The following options control the behavior of
XDMCP. Enables XDMCP and broadcasts BroadcastQuery packets to the net‐
work. The first responding display manager will be chosen for the ses‐
sion. XDMCP has an additional display qualifier used in resource
lookup for display-specific options. This option sets that value. By
default, it is "MIT-Unspecified", which is not very useful. When test‐
ing XDM-AUTHENTICATION-1, a private key is shared between the server
and the manager. This option sets the value of that private data,
although because it is on the command line, it is not very private.
XDMCP-specific value that allows the display manager to identify each
display so that it can locate the shared key. Enables XDMCP and sends
IndirectQuery packets to the specified host. Causes the X server to
terminate after one session. Uses an alternate port number for XDMCP
packets. Must be specified before any -query, -broadcast, or -indirect
options. Enables XDMCP and sends Query packets to the specified host.
The following options are for the controlling the loadable portion of
the X server. See the Modular Extensible Server section for more
information. Specifies the name of a configuration file to use to con‐
figure the loadable X server. The default configuration file is
/usr/lib/X11/Xserver.conf. Specifies the name of an error file to use
to redirect error messages. The default is to send error messages to
standard error. Displays the libraries specified in the configuration
file that will be used by the loadable server. Displays the default
libraries that will be used by the loadable server. Displays the merg‐
ing of the default and configured lists of libraries, showing the
resultant list to be used by the loadable server.
The following options are device dependent and proprietary. When the
server is run on multiscreen-capable platforms, selected device-depen‐
dent options take an optional screen-specification argument. Omitting
the screen-specification argument defines the parameter for all avail‐
able screens. Specifies the number of buttons on the pointer device.
The default is 3 for a mouse device and 4 for a tablet device. Sets
the color of black pixels for the screen. The color argument can be a
named color from the rgb database or a number sign (#) followed by a
hexadecimal number. Disable screen n. Sets the dots-per-inch for the
x and y coordinates. Sets the dots-per-inch for the x coordinates.
Sets the dots-per-inch for the y coordinates. Attaches the bottom edge
of the screen specified by scr1 to the screen specified by scr2.
Attaches the left edge of the screen specified by scr1 to the screen
specified by scr2. Attaches the right edge of the screen specified by
scr1 to the screen specified by scr2. Attaches the top edge of the
screen specified by scr1 to the screen specified by scr2. Override
screen disabling for screen n. Disable XKB extension. Only enable
screen n. Set screen width and height. List physical screens to place
in logical order. If the screens list does not end in a period, all
physical screens not listed will be added to the end of the logical
order. If the list ends in a period, all remaining physical screens
will be disabled. Sets the visual class for the root window of the
screen. Possible values are StaticGray, StaticColor, PseudoColor,
GrayScale, TrueColor, and DirectColor. Sets the color of white pixels
for the screen. The syntax for color is the same as for the argument
to the -bp option. Base directory for XKB layout files. XKB keyboard
description to load on startup. File that contains default XKB
keymaps. This is /usr/lib/X11/xkb/keymaps.dir by default.
DESCRIPTION
The Xdec command starts the X server. The Xdec command supports the
run-time loading and execution of X server libraries on Tru64 UNIX
platforms with graphics devices. The command loads appropriate
libraries to handle graphics devices installed on the workstation and
you can configure the command to use any or all of the extension
libraries available on your workstation.
STARTING THE SERVER
The server is usually started from the X Display Manager program xdm.
The xdm daemon, started from the system initialization script
/sbin/rc3.d/S95xlogin, starts the Xdec command when the system enters
multiuser mode. Xdm takes care of keeping the server running, prompt‐
ing for usernames and passwords, and starting up the user sessions. It
is easily configured for sites that want to provide consistent inter‐
faces for novice users (loading convenient sets of resources and start‐
ing up a window manager, a clock, and a selection of terminal emulator
windows).
When the X server starts up, it takes over the display. If you are
running on a workstation whose console is the display, you cannot log
into the console while the server is running.
NETWORK CONNECTIONS
The X server supports connections made using the following reliable
byte-streams: The server listens on port 6000+n, where n is the display
number. The X server uses /tmp/.X11-unix/Xn as the filename for the
socket, where n is the display number. The X server uses shared mem‐
ory. The server responds to connections to object X$Xn, where n is the
display number.
RESTRICTIONS
If options not listed in this reference page are used, the server may
fail. Using invalid options for the X server in the
/usr/lib/X11/xdm/Xservers file may cause the X server to start and fail
repetitively.
Multiscreen configurations may contain any configuration display
devices.
To connect two screens, two command line options must be issued.
Attaching two screens using only one -edge_ argument produces a one-way
mouse-travel path. You can create a wrap-around mouse path by attaching
noncontiguous screen edges. The -edge_ arguments are disabled on sin‐
gle screen systems.
Nonsensical screen connections are not allowed; the top edge of a par‐
ticular screen must be connected with the bottom edge of another
screen, and the right edge of a particular screen must be connected
with the left edge of another screen. Left and right edges cannot be
connected to top or bottom edges.
EXAMPLES
The following example specifies that screen 0 has a resolution of
100x100 dots-per-inch and screen 1 has a resolution of 75x70 dots-per-
inch:
Xdec -dpi0 100 -dpix1 75 -dpiy1 70
If no screen is specified, the value specified is used for all screens.
If the screen resolution is not specified using command line options, a
default value based on pixel dimensions and screen size is calculated
for each screen.
The following example specifies that black pixels on screen 1 have the
hexadecimal value 3a009e005c0 prefixed with a number sign (#) and white
pixels on screen 1 are color "wheat" from the X rgb color database.
Xdec -bp1 #3a009e005c0 -wp1 wheat
For monochrome display devices, values of 0 and 1 are the only valid
pixel colors.
To specify the default visual class of a root window on a particular
screen, append the screen number (0, 1, or 2) to the -vclass command
line option. Possible visual classes are: StaticGray, StaticColor,
PseudoColor, GrayScale, TrueColor, and DirectColor. The following
example specifies that the screen 0 root window is a TrueColor visual,
and the screen 1 root window is a PseudoColor visual.
Xdec -class0 TrueColor -vclass1 PseudoColor
The following example attaches screen 1 above screen 0 and screen 2 to
the right of screen 0 (an L-shaped configuration):
Xdec -edge_top0 1 -edge_bottom1 0 -edge_right0 2 -edge_left2 0
The following example is identical to the default state (a horizontal
line) with the addition of a wraparound from screen 0 to screen 2:
Xdec -edge_left0 2 -edge_right0 1 -edge_left1 0 -edge_right1 2 \
-edge_left2 1 -edge_right2 0
SECURITY
The X server implements a simplistic authorization protocol, MIT-MAGIC-
COOKIE-1. This protocol uses data private to authorized clients and
the server. It is a rather trivial scheme; if the client passes autho‐
rization data that is the same as the server has, it is allowed access.
This scheme is worse than the host-based access control mechanisms in
environments with unsecure networks because it allows any host to con‐
nect, given that it has discovered the private key. But in many envi‐
ronments, this level of security is better than the host-based scheme
because it allows access control per-user instead of per-host.
The authorization data is passed to the server in a private file named
with the -auth command line option. Each time the server is about to
accept the first connection after a reset (or when the server is start‐
ing), it reads this file. If this file contains any authorization
records, the local host is not automatically allowed access to the
server, and only clients which send one of the authorization records
contained in the file in the connection setup information will be
allowed access. See the Xau(3X) manual page for a description of the
binary format of this file.
The X server also uses a host-based access control list for deciding
whether to accept connections from clients on a particular machine. If
no other authorization mechanism is being used, this list initially
consists of the host on which the server is running as well as any
machines listed in the file /etc/Xn.hosts, where n is the display num‐
ber of the server. Each line of the file should contain either an
Internet hostname (for example, expo.lcs.mit.edu) or a DECnet hostname
in double colon format (for example, hydra::). There should be no
leading or trailing spaces on any lines. For example:
joesworkstation corporate.company.com star:: bigcpu::
Users can add or remove hosts from this list and enable or disable
access control using the xhost command from the same machine as the
server.
SIGNALS
The X server attaches special meaning to the following signals: This
signal causes the server to close all existing connections, free all
resources, and restore all defaults. It is sent by the display manager
whenever the main user's main application (usually an xterm or window
manager) exits to force the server to clean up and prepare for the next
user. This signal causes the server to exit cleanly. This signal is
used quite differently from either of the above. When the server
starts, it checks to see if it has inherited SIGUSR1 as SIG_IGN instead
of the usual SIG_DFL. In this case, the server sends a SIGUSR1 to its
parent process after it has set up the various connection schemes. Xdm
uses this feature to recognize when it is possible to connect to the
server.
FONTS
Fonts are usually stored as individual files in directories. The X
server can obtain fonts from directories and/or from font servers. The
list of directories and font servers the X server uses when trying to
open a font is controlled by the font path. Although most sites will
choose to have the X server start up with the appropriate font path
(using the -fp option described previously), it can be overridden using
the xset program.
The default font path for the X server contains the following three
directories: This directory contains many miscellaneous bitmap fonts
that are useful on all systems. It contains a family of fixed-width
fonts, a family of fixed-width fonts from Dale Schumacher, several Kana
fonts from Sony Corporation, two JIS Kanji fonts, two Hangul fonts from
Daewoo Electronics, two Hebrew fonts from Joseph Friedman, the standard
cursor font, two cursor fonts from Digital Equipment Corporation, and
cursor and glyph fonts from Sun Microsystems. It also has various font
name aliases for the fonts, including fixed and variable. This direc‐
tory contains bitmap fonts contributed by Adobe Systems, Inc., Digital
Equipment Corporation, Bitstream, Inc., Bigelow and Holmes, and Sun
Microsystems, Inc. for 75 dots-per-inch displays. An integrated selec‐
tion of sizes, styles, and weights are provided for each family. This
directory contains 100 dots-per-inch versions of some of the fonts in
the 75dpi directory.
The following font directories are among those that can be added to the
font path by xdm after it starts the X server:
/usr/lib/X11/fonts/decwin/75dpi /usr/lib/X11/fonts/decwin/100dpi
These directories contain the 75dpi fonts and 100dpi fonts used by the
out-of-the-box applications such as dxterm. This directory contains
outline fonts for Bitstream's Speedo rasterizer. A single font face --
in normal, bold, italic, and bold italic -- is provided, contributed by
Bitstream, Inc. This directory contains "Type 1" (PostScript) format
outline fonts for IBM's rasterizer. This directory contains "Type 1"
(PostScript) format outline fonts contributed by Adobe Systems, Inc.
Font databases are created by running the mkfontdir program in the
directory containing the compiled versions of the fonts (the files).
Whenever fonts are added to a directory, mkfontdir should be rerun so
that the server can find the new fonts. If mkfontdir is not run, the
server will not be able to find any fonts in the directory.
MODULAR EXTENSIBLE SERVER
The Xdec command is simply a bootstrap program that loads the X server
components and transfers execution to them. The command also contains
some utility routines to allow the X server components to load even
more components.
The X server is composed of several sections: System components are the
system libraries used for such things as math routines and DECnet
interfaces. Core components form the core portion of the X server.
They include operating system interfaces, X protocol interfaces, rou‐
tines for handling server resources, window trees, fonts, some generic
frame buffer handlers, and routines for interfacing with the worksta‐
tion device driver (the interface to the frame buffers, keyboard, and
pointer devices). Device handler components are made available to the
workstation device driver interface. The interface loads them to handle
specific graphics devices found on the system. The components contain
code for initializing the graphics devices and for performing special‐
ized drawing operations tailored for the specific hardware on the
device. Extension components contain the code for X extensions. The
components are loaded by the core components from a configurable list.
Some extensions may only be partially loaded at server initialization
time to save memory. When the first client requests the use of an
extension, the extension code loads the remainder of the extension and
continues processing the requests. Some extensions may further load
device-specific code to provide special handling of graphics devices or
input devices found on the system. By default, the core components
contain font handling code for bitmap and some scalable fonts. The core
components can also load additional font renderers to handle different
font formats. One font renderer is a communication interface to a font
server.
When the Xdec command is started, it uses a set of internal default
lists of components to build an X server. It also reads a system con‐
figuration file (/usr/var/X11/Xserver.conf or the file specified by the
-config option) to supplement or replace components on the lists. The
command loads all system and core components and then transfers execu‐
tion to the core components.
Workstation driver interface code in the core components then queries
the system for graphics and input device types and loads appropriate
components from the device and input lists. If the workstation driver
interface cannot find a component for a device, it will force the X
server to exit. If a graphics device is a generic dumb frame buffer,
the device list should contain an entry mapping the device type to a
generic frame buffer handler (see below).
The core components then load the list of extensions provided and ini‐
tialize the extensions. Some extensions may load further device-spe‐
cific components from the sublists provided to them in the configura‐
tion file.
The core components also load any font renderers, transport handlers,
and authorization protocol methods specified in the configurations.
The X server then begins to accept connections.
When the X server resets itself (usually when the last client has
exited), all extension and font renderer components are unloaded and
then re-initialized when the X server begins to restart itself. In this
way, extensions or font renderers which have been used can re-install
themselves as small stub components, taking up much less memory, until
they are accessed again. For instance, if you want to have PostScript
or PEX as an available extension at all times but do not wish to use up
memory, they might be loaded initially as a stub component, taking up
only a fraction of their total required memory. When you run a client
that needs to use them, the full extension is used. When you have fin‐
ished using that client, you can log out of your session (if using xdm)
which will reset the X server, unload the full extension, and reinstall
only the stub component until you need to use the extension again,
leaving memory for other uses.
CONFIGURATION FILE SYNTAX
The configuration file syntax is quite simple. The following are key
tokens recognized by the Xdec command when reading the file. When !
is encountered, the remainder of the line is ignored. Comments in the
configuration file should be proceeded on each line by a !. Where com‐
ponent is one of
system
core
device
extensions
font_renderers
auth_protocols
transports
input
When specifying the keyword replace after the keyword core, the
default list of core X server libraries is replaced by the con‐
figured list. < library_name library_file_name [ initializa‐
tion_routine_name [ device_name ] ] [ sub_library_list ] > Spec‐
ifies the name of the library. This name is used to reference
internal data structures within the library and may also be used
to construct the library initialization routine name. Specifies
the name of the file containing the library. The file is a
shared library and usually has the extension This routine is
used to initialize the component, if appropriate. The system
and core libraries do not have initialization routines. If no
name is specified, the name will be constructed from the library
name. For device handlers and extension sublists, the device
name matches the name stored on a graphics device option card.
The name is used to match a library to a graphics device. This
name must be provided for device handler and extension sublist
components that handle graphics devices. Specifies a list of
libraries made available for loading to an extension. The syntax
is the same as the library_list syntax except that no further
sublists are allowed. Specifies a colon separated list of
directories to search for finding libraries. If the list does
not begin or end with a colon, it will be used as the exclusive
search path for libraries. If the list begins or ends with a
colon, it is either appended or prepended to the default library
search path, which may either be a default search path as speci‐
fied by the system loader or the search path specified by the
environment variable LD_LIBRARY_PATH. (See the manpage for
/sbin/loader for more details.) Specifies the list of arguments
to be appended to the command line arguments passed to the X
server. Arguments can span multiple lines and no parsing is done
by the Xdec command. The options -config and -errorFile are spe‐
cific to the Xdec bootstrap command and cannot be specified in
the configuration file.
The Xdec command searches for libraries using the library_path speci‐
fied in the configuration file or the LD_LIBRARY_PATH environment vari‐
able. Each component in the colon separated path is searched. In addi‐
tion, for each component in the path, the path component/Xserver is
also searched so that X server libraries can be more neatly maintained
in a subdirectory. The default search path is
/usr/shlib/Xserver:/usr/shlib.
The default system installation provides a sample configuration file
/usr/lib/X11/Xserver.conf. It contains comments and shows examples for
setting up library lists, library sublists, the library search path,
and sample argument lists.
GENERIC FRAME BUFFER HANDLERS
If you install a generic frame buffer device that has the following
characteristics, you can handle the frame buffer with the generic frame
buffer handlers provided with the core X server components: Does not
require any initialization beyond that done by the device driver. Is a
continuous array of packed pixels with a depth of 1, 8, 16, or 32 bits.
Can be accessed through the workstation device driver.
The entries you would need in the configuration file for initializing
the device are as follows for the 1-, 8-, 16-, and 32-bit deep devices,
where device_name matches the moduleID of the graphics device:
< mfb libmfb.so mfbScreenInit device_name > <
cfb libcfb.so cfbScreenInit device_name > <
cfb16 libcfb16.so cfb16ScreenInit device_name > <
cfb32 libcfb32.so cfb32ScreenInit device_name >
DIAGNOSTICS
If run from xdm, errors are typically logged in the file
/usr/lib/X11/xdm/xdm-errors.
FILES
Initial access control list Bitmap font directories Outline font direc‐
tories DECwindows font directories Color database UNIX domain socket
Error log file Default configuration file Loadable components Exe‐
cutable image
SEE ALSOX(1X), bdftopcf(1X), mkfontdir(1X), xauth(1X), xdm(1X), xhost(1X),
xset(1X), xsetroot(1X), xterm(1X)
X Window System Protocol, Definition of the Porting Layer for the X v11
Sample Server, Strategies for Porting the X v11 Sample Server,
Godzilla's Guide to Porting the X V11 Sample Server
Xdec(1X)
