Section: User Commands (1)
Updated: xorg-server 1.16.4
The X server is usually started from the X Display Manager program xdm?(1) or a similar display manager program. This utility is run from the system boot files and takes care of keeping the server running, prompting for usernames and passwords, and starting up the user sessions.
Installations that run more than one window system may need to use the xinit?(1) utility instead of a display manager. However, xinit is to be considered a tool for building startup scripts and is not intended for use by end users. Site administrators are strongly urged to use a display manager, or build other interfaces for novice users.
The X server may also be started directly by the user, though this method is usually reserved for testing and is not recommended for normal operation. On some platforms, the user must have special permission to start the X server, often because access to certain devices (e.g. /dev/mouse) is restricted.
When the X server starts up, it typically takes over the display. If you are running on a workstation whose console is the display, you may not be able to log into the console while the server is running.
Many X servers have device-specific command line options. See the manual pages for the individual servers for more details; a list of server-specific manual pages is provided in the SEE ALSO section below.
All of the X servers accept the command line options described below. Some X servers may have alternative ways of providing the parameters described here, but the values provided via the command line options should override values specified via other mechanisms.
Some X servers accept the following options:
X servers that support XDMCP have the following options. See the X Display Manager Control Protocol specification for more information.
X servers that support the XKEYBOARD (a.k.a. "XKB") extension accept the following options. All layout files specified on the command line must be located in the XKB base directory or a subdirectory, and specified as the relative path from the XKB base directory. The default XKB base directory is /usr/lib/X11/xkb.
The X server supports client connections via a platform-dependent subset of the following transport types: TCP/IP, Unix Domain sockets, DECnet, and several varieties of SVR4 local connections. See the DISPLAY NAMES section of the X?(7) manual page to learn how to specify which transport type clients should try to use.
The X server implements a platform-dependent subset of the following authorization protocols: MIT-MAGIC-COOKIE-1, XDM-AUTHORIZATION-1, XDM-AUTHORIZATION-2, SUN-DES-1, and MIT-KERBEROS-5. See the Xsecurity?(7) manual page for information on the operation of these protocols.
Authorization data required by the above protocols 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 manual page for a description of the binary format of this file. See xauth?(1) for maintenance of this file, and distribution of its contents to remote hosts.
The X server also uses a host-based access control list for deciding whether or not 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 (e.g. expo.lcs.mit.edu) or a DECnet hostname in double colon format (e.g. hydra::) or a complete name in the format family:name as described in the xhost?(1) manual page. There should be no leading or trailing spaces on any lines. For example:
joesworkstation corporate.company.com star:: inet:bigcpu local:
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.
If the X FireWall Proxy (xfwp) is being used without a sitepolicy, host-based authorization must be turned on for clients to be able to connect to the X server via the xfwp. If xfwp is run without a configuration file and thus no sitepolicy is defined, if xfwp is using an X server where xhost + has been run to turn off host-based authorization checks, when a client tries to connect to this X server via xfwp, the X server will deny the connection. See xfwp?(1) for more information about this proxy.
The X protocol intrinsically does not have any notion of window operation permissions or place any restrictions on what a client can do; if a program can connect to a display, it has full run of the screen. X servers that support the SECURITY extension fare better because clients can be designated untrusted via the authorization they use to connect; see the xauth?(1) manual page for details. Restrictions are imposed on untrusted clients that curtail the mischief they can do. See the SECURITY extension specification for a complete list of these restrictions.
The X server attaches special meaning to the following signals:
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.
The default font path is /usr/share/fonts/X11/misc,/usr/share/fonts/X11/cyrillic,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins .
A special kind of directory can be specified using the catalogue: prefix. Directories specified this way can contain symlinks pointing to the real font directories. See the FONTPATH.D section for details.
You can specify a special kind of font path in the form catalogue:<dir>. The directory specified after the catalogue: prefix will be scanned for symlinks and each symlink destination will be added as a local fontfile FPE.
The symlink can be suffixed by attributes such as 'unscaled', which will be passed through to the underlying fontfile FPE. The only exception is the newly introduced 'pri' attribute, which will be used for ordering the font paths specified by the symlinks.
An example configuration:
75dpi:unscaled:pri=20 -> /usr/share/X11/fonts/75dpi ghostscript:pri=60 -> /usr/share/fonts/default/ghostscript misc:unscaled:pri=10 -> /usr/share/X11/fonts/misc type1:pri=40 -> /usr/share/X11/fonts/Type1 type1:pri=50 -> /usr/share/fonts/default/Type1
This will add /usr/share/X11/fonts/misc as the first FPE with the attribute 'unscaled', second FPE will be /usr/share/X11/fonts/75dpi, also with the attribute 'unscaled' etc. This is functionally equivalent to setting the following font path:
/usr/share/X11/fonts/misc:unscaled, /usr/share/X11/fonts/75dpi:unscaled, /usr/share/X11/fonts/Type1, /usr/share/fonts/default/Type1, /usr/share/fonts/default/ghostscript
Protocols: X Window System Protocol, The X Font Service Protocol, X Display Manager Control Protocol
The sample server was originally written by Susan Angebranndt, Raymond Drewry, Philip Karlton, and Todd Newman, from Digital Equipment Corporation, with support from a large cast. It has since been extensively rewritten by Keith Packard and Bob Scheifler, from MIT. Dave Wiggins took over post-R5 and made substantial improvements.
Tutoriais de Tecnologia Web