Xdec, Xserver - X Window System server
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 control 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. Enables or disables the graphical interface to the AccessX keyboard enhancement utility. This utility provides enhancements to the X Window System that help users with different disabilities interact with workstations. See the accessx(1X) reference page. Sets the audit trail level. The default level is 1, meaning only connection rejections are reported. Level 2 additionally reports all successful connections and disconnections. Level 0 turns off the audit trail. Audit lines are sent as standard error output. 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). 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 configuration file is defined or if the default fs_cache_config file exists, glyph caching will be enabled when the X server is reading from a font server for those fonts whose code sets are specified in the file. Sets the visual class for the root window of color screens. The class numbers are those specified in the X protocol. 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.
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 network. The first responding display manager will be chosen for the session. 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 testing 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. Yet another XDMCP-specific value, this one 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. 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 configure 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 merging 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 Digital specific. When
the server is run on multiscreen-capable platforms, selected device-dependent
options take an optional screen-specification argument. Omitting the screen-specification
argument defines the parameter for all available 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
argument can be a named color from the
database or a number sign (#) followed by a hexadecimal
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
to the screen specified by
Attaches the left edge of the screen specified by
to the screen specified by
Attaches the right edge of the screen specified by
to the screen specified by
Attaches the top edge of the screen specified by
to the screen specified by
Override screen disabling for screen
Disable XKB extension.
Only enable screen
Set screen width and height.
List physical screens to place in logical order. If the
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
Sets the color of white pixels for the screen. The syntax
is the same as for the argument to the
Base directory for XKB layout files.
XKB keyboard description to load on startup.
File that contains default XKB keymaps. This is
command starts the X server. The
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.
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, prompting for usernames and passwords, and starting up the user sessions. It is easily configured for sites that want to provide consistent interfaces for novice users (loading convenient sets of resources and starting 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.
The X server supports connections made using the following reliable
The server listens on port 6000+n,
is the display number.
The X server uses
as the filename for the socket, where
is the display number.
The X server uses shared memory.
The server responds to connections to object
is the display number.
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 single screen systems.
Nonsensical screen connections are not allowed; the top edge of a particular
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.
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
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 authorization 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 connect, given that it has discovered the private key. But in many environments, 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 starting), 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 number 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
command from the same machine as
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
or window manager) exits to force the server to clean up and prepare for the
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.
uses this feature to recognize when it is possible to connect
to the server.
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 directory 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 selection 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:
These directories contain the 75dpi fonts and 100dpi fonts used by the Digital out-of-the-box applications such as dxcalendar and 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
program in the directory containing the compiled versions of the fonts (the
files). Whenever fonts are added to a directory,
should be rerun so that the server can find the new fonts.
is not run, the server will not be able to
find any fonts in the directory.
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, routines for handling server resources, window trees, fonts, some generic frame buffer handlers, and routines for interfacing with the workstation 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 specialized 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 configuration 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 execution 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 initialize the extensions. Some extensions may load further device-specific components from the sublists provided to them in the configuration 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 Post Script 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 finished 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.
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 component is one of
The Xdec command searches for libraries using the library_path specified in the configuration file or the LD_LIBRARY_PATH environment variable. Each component in the colon separated path is searched. In addition, 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.
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 >
If run from
xdm, errors are typically logged in the
Initial access control list
Bitmap font directories
Outline font directories
DECwindows font directories
UNIX domain socket
Error log file
Default configuration file
X(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