Xsco(X) 19 June 1992 Xsco(X) Name Xsco - server for 80386- and 80486-based computers running Open Desktop Syntax Xsco [:displayno] [option ...] Description Xsco is an X11 display server (Release 4) for 80386- and 80486-based com- puters running Open Desktop. It is most often started with a display manager or the startx startup script. To shut down the server, press <Alt><SysReq>. On some keyboards, this is <SysReq>. Options :displayno sets the display number of the server. For example, Xsco :1 allows clients with DISPLAY= servername:1 to establish connections. The default displayno is 0. -h[elp] prints options and exits -a n specifies pointer acceleration. n is the ratio of how much is reported to how much the user actually moves the pointer. Pointer acceleration can also be changed with the xset utility. -auth file specifies a file that contains a collection of authori- zation records used to authenticate access bc disables certain kinds of error checking for bug compa- tibility with previous releases (for example, to work around bugs in R2 and R3 xterms and toolkits). This option does not use a dash (-). -bs disables backing store on all screens -cc visualclass specifies the default visual class. The following are legal values for visualclass: 0 StaticGray 1 GrayScale 2 StaticColor 3 PseudoColor 4 TrueColor 5 DirectColor Not all graphics adapters support all six visual classes. Note that the -static option overrides this option. -co databasename sets the name of the RGB color database. databasename is the name of the color database, and may include a path. databasename must not include the .dir and .pag extensions of the files that constitute the database. The -co option duplicates the -fr option. -crt device specifies the console multiscreen on which the server is displayed. device must be a complete device name, such as /dev/tty03. -d vendor.model.class.mode specifies your graphics adapter and its video mode (resolution). The file /usr/lib/grafinfo/grafdev con- tains the system-wide default string that is used on each tty when the -d option is not specified. Some examples of setting the display type or resolution with the -d option are: Xsco -d ibm.vga.vga.640x480-16 Xsco -d paradise.vga1024.svga.640x480-256 Xsco -d sigma.legend.vga.800x600-16 Xsco -d trident.tvga.svga.1024x768-16 Xsco -d trident.tvga.svga.1024x768-256 -evsync compensates for some timing problems between the event driver and the system clock. -fc font sets the cursor font. The default is /usr/lib/X11/fonts/misc/cursor. Use this only if you have a special purpose cursor font. -fn font sets the default text font. The default is fixed. Fonts are found in /usr/lib/X11/fonts. Most, however, are special purpose fonts. To display them, use the xfd client. -fp fontpath sets the font search path. By default, the server searches /usr/lib/X11/fonts/misc, /usr/lib/X11/fonts/75dpi, and /usr/lib/X11/fonts/100dpi. Use this option only if the fonts database was installed in a different directory. Note that the font search path can also be set with the xset command. -fr databasename sets the color database. The default is /usr/lib/X11/rgb. Use this option only if you have renamed the color database files, rgb.dir or rgb.pag, or moved them to a different directory. Note that this option is the same as the -co option. -I causes all remaining command line arguments to be ignored. Use this option for troubleshooting. -logo turns on the logo screen saver. This places the X logo on your screen if you do not use your screen for 10 minutes. Note that you must also use the -v off option to see the X logo. To specify how long the server must be idle before it activates the screen saver, use the -save option. -nologo turns off the logo screen saver. You can also specify this option as nologo (without the dash character). The -v option overrides this option. -nice n alters the priority of the server process by adding n to the value of the current nice. The n value is from 0 to 39. By default, the server process is assigned the value of 0. Lower values correspond to higher scheduling priority. -p n specifies how often (in seconds) to change the screen- saver pattern. This option works in conjunction with the -logo option. -r turns off auto-repeat. By default, auto-repeat is on. r turns on auto-repeat -save n activates the screen-saver after n seconds of non-use. The default is 600. This option reduces wear on your screen. If you use this option with the -logo option, the X logo moves around the screen according to how you specify the -p option. If n is ``0'', the screen saver is not activated. -static defaults to a static color visual class. This option overrides the -cc option. -su disables save under support on all screens -t threshold sets pointer acceleration threshold in pixels (that is, after how many pixels pointer acceleration should take effect). Pointer acceleration threshold can also be changed with the xset utility. -to timeout sets default connection timeout (the time allowed for the client to complete connection) in seconds -v on specifies video blanking for screen-saver. The default is on. This blanks out your screen after 10 minutes of non-use. This option overrides the -logo and -nologo options. To specify how long the server must be idle before it activates the video blanking, use the -save option. -v off specifies screen-saver without video blanking. Instead, the root window pattern and X logo cover the screen. The pattern shifts periodically as specified with the -p option. -wm forces the default backing-store of all windows to be WhenMapped; a work-around for getting backing-store to apply to all windows Colors You can display up to 256 colors simultaneously on your screen, depending on the capabilities of the graphics adapter that you have installed on your system and the entries that you select when you run mkdev graphics. The RGB database files, rgb.dir and rgb.pag, are compiled using the rgb utility from the file rgb.txt. Each line of the rgb.txt file consists of three color values and a color name. The color values are decimal num- bers from 0 to 255 for the red, green, and blue components of the color. A typical line looks like this: 35 35 142 Navy Blue This entry defines Navy Blue as consisting of 35/255ths of the maximum possible intensity of red, 35/255ths of the maximum possible intensity of green, and 142/255ths of the maximum possible intensity of blue. The server is case-insensitive when searching for color names, so ``navy blue'' or ``Navy BLUE'' finds the entry above, for example. The server is sensitive to spaces in color names, so it does not equate ``Navy BLUE'' and ``NavyBLUE.'' Remember that the precision of different adapters varies. The exact same color values may not produce the exact same shade of that color on dif- ferent monitors. Screen-switching The server supports screen-switching between 10 or 12 console mul- tiscreens, depending on the number of function keys on your keyboard. The default screen-switching key sequence is <Ctrl><Alt><Fn>, where <Fn> is function key 1 through 10 or 1 through 12. You can redefine the switch-screen key sequence using the xswkey program. The following conditions must be met: (1) you must be at the console; or (2) the DISPLAY environment variable must be set and at least one server must be running. The syntax of the xswkey program is: xswkey -[cas] c stands for the <Ctrl> key; a stands for the <Alt> key; and s stands for the <Shift> key. Specify the key sequence you want with xswkey and you can then use that key sequence with any function key. For example, to specify that you want to use <Ctrl> and <Shift> along with a function key, type: xswkey -cs Then, you switch screens by pressing <Ctrl>-<Shift>-<Fn>. To use only function keys without <Ctrl>, <Alt>, or <Shift>, use xswkey with only a hyphen and no arguments: xswkey - _________________________________________________________________________ NOTE If you are running a client on one multiscreen and you switch to another screen, the client on the original screen stops writing to the server until you switch back to that screen. _________________________________________________________________________ Environment Variables XENVIRONMENT points to a file with your default resources. DISPLAY specifies that clients open window on your display. See the X(X) manual page. Security The server provides two mechanisms for controlling client access to a display. These mechanisms include: + xhost + MIT-MAGIC-COOKIE-1 authorization protocol With earlier versions of the server, xhost was the only method available for protecting a server from unwanted connections. Although, this approach is still useful, however, it is not as secure as the MIT-MAGIC- COOKIE-1 protocol, which is new to the Release 4 version of the server. Both methods are explained below. The server can use an access-control list to decide whether or not to accept connections from clients. This list initially consists of the host on which the server is running as well as any computers listed in the /etc/Xn.hosts file, where n is the server's display number. Each line of the file should contain an Internet host name (for example, expo.lcs.mit.edu). There should be no leading or trailing spaces on any lines. For example: joesworkstation corporate.company.com You can add or remove hosts from this list and enable or disable access control using xhost. For example: % xhost +janesworkstation janesworkstation being added to access control list % xhost + all hosts being allowed (access control disabled) % xhost - all hosts being restricted (access control enabled) % xhost access control enabled (only the following hosts are allowed) + joesworkstation + janesworkstation + corporate.company.com Unlike some window systems, X does not have any notion of window opera- tion 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. The xhost method for controlling access to a display, as described ear- lier, allows you to specify machines that have permission to connect to a server. This approach is fine if you know that you can trust all of the users on a given machine. However, if you are interested in maintaining tighter restrictions on which clients can access a display, use the new Release 4 authorization protocol, named MIT-MAGIC-COOKIE-1. This protocol is implemented by scologin, the Xsco server, Xlib, and xauth. Under this approach, a client that wishes to access a display must know the access key, called a ``magic cookie,'' that has been assigned to the server. When a client requests access to a display, it sends a magic cookie and if it matches the server's magic cookie, a connection is allowed, regardless of the location of the client. If the magic cookie is not correct, the server refuses a connection. Upon system startup, scologin generates a random magic cookie and stores it in a file that can only be read by the server. This magic cookie is also placed in $HOME/.Xauthority, by default, when a user logs in to the system. .Xauthority now contains the information needed for that user to connect to the server. The same magic cookie needs to exist in $HOME/.Xauthority on a remote machine for a client or remote user to gain access to the server. Use the xauth program to edit the .Xauthority file and pass the magic cookie to other machines. For more information on the xauth command, refer to the xauth(X) manual page. Note that if you run clients that were compiled for previous releases of the server and you use the MIT-MAGIC-COOKIE-1 protocol, the clients are not able to connect with the server by default. You must run xhost +yourmachinename for the clients to gain access to the server. Clients that are not compiled with X11 R4 (or later) libraries, such as those in the Open Desktop 1.1 Development System, cannot recognize the MIT-MAGIC- COOKIE-1 protocol. Note too that it is not recommended that you use both the xhost and the MIT-MAGIC-COOKIE-1 protocols at the same time. This is because the xhost command overrides the security measures the authorization protocol pro- vides. Signals The server attaches special meaning to the following signals: SIGHUP causes the server to close all existing connections, free all resources, and restore all defaults. It is sent by the dis- play manager whenever the user's main application (usually an xterm or window manager) exits to force the server to clean up and prepare for the next user. If you switch away from the server to another console multiscreen, the server waits for you to switch back before responding to this signal. SIGTERM causes the server to exit cleanly. If you switch away from the server to another console multiscreen, the server waits for you to switch back before responding to this signal. _________________________________________________________________________ NOTE Do not kill the server with the kill -9 command or by issuing SIGKILL. If the server does not exit cleanly, it leaves the key- board and display in an unusable state. _________________________________________________________________________ Fonts Fonts are usually stored as individual files in directories. The font path controls the list of directories where the server looks when trying to open a font. Although most sites may choose to have the server start up with the appropriate font path (using the -fp option mentioned ear- lier), you can use the xset program to override it. The default font path for the server is: /usr/lib/X11/fonts/misc; /usr/lib/X11/fonts/75dpi; /usr/lib/X11/fonts/100dpi The default font path includes several miscellaneous fonts that are use- ful 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 vari- able, among others. You create font databases by running mkfontdir in the directory contain- ing the compiled versions of the fonts (that is, the .snf files). When- ever you add fonts to a directory, run mkfontdir so the server can find the new fonts. The server cannot find any fonts in the directory if you do not run mkfontdir. Key mapping Xsco maintains two tables in memory that allow keyboard mapping to be modified dynamically. One table, called the ``modifiers list,'' contains the server keycodes corresponding to the keyboard's modifier keys, such as <Shift>, <Alt>, and <Lock>. The second table, called the ``keymap table,'' contains lists of key symbols (``keysyms'') that correspond to each keycode/modifier combination. Many non-U.S. keyboards have more than two symbols on some keys. To access additional symbols, a modifier known as ``Mode Switch'' switches between two groups of key symbols. Mode Switch is also known as the ``group modifier.'' The first two keysyms in the list are called Group 1. The third and fourth keysyms are called Group 2. When the group modifier is off, a keysym from Group 1 is used. When the group modifier is on, a keysym from Group 2 is used. The state of modifiers determines which keysym in the group is used. The first keysym in the selected keysym group is used when the Shift and Lock modifiers are off. The second keysym in the group is used in the following circumstances: + Shift modifier is on + Lock modifier is on and the keysym is an uppercase character + Lock modifier is on and corresponds to Shiftlock The X protocol defines how the first four keysyms are interpreted, but it does not limit the number of keysyms that may be associated with each keycode. If fewer than four keysyms are specified, the following rules apply: + If only one keysym is specified, it is used as the first keysym in both Group 1 and Group 2. + If only the Group 1 keysyms are specified, then they are used for Group 2 also. + If only three keysyms are specified, then the second keysym in Group 2 is ``NoSymbol''. If necessary, you can include the ``VoidSymbol'' keysym in a keymap to fine tune the key mapping. By default, the group modifier is not defined. You can make any key the group modifier by attaching a modifier bit (``Mod1'' though ``Mod5'') to the desired key in the modifiers list. You can monitor the effect of modifier keys and key mapping with the xev utility. It is the responsi- bility of the clients to interpret the association of the modifier bit with the new keysyms. Xsco establishes initial keyboard mapping by reading a configuration file, /usr/lib/X11/.Xsco.cfg that is created by the xsconfig utility. Users that want custom server configurations can maintain customized .Xsco.cfg files in their $HOME directories. Once Xsco is running, you can modify any entry in the modifiers list or keymap table with the xmod- map utility. Files System-wide keyboard configuration file: /usr/lib/X11/xsconfig/.Xsco.cfg System-wide default for graphics adapters and modes: /usr/lib/grafinfo/grafdev Graphics information files: /usr/lib/grafinfo/vendor/model.xgi Initial access control list: /etc/X*.hosts Font directories: /usr/lib/X11/fonts/misc /usr/lib/X11/fonts/75dpi /usr/lib/X11/fonts/100dpi Color database: /usr/lib/X11/rgb.txt /usr/lib/X11/rgb.dir /usr/lib/X11/rgb.pag Known Limitations If you kill the server in some way other than shutting it down with the <SysReq> key, you may not be able to type on the console. To remedy this, run the cleanscreen program by typing /etc/cleanscreen at the op- erating system prompt from a terminal. If you kill the server in some way other than with the <SysReq> key and you cannot log in as root, type <Ctrl>D after running the cleanscreen program. Keyboard click and bell volume are not settable. See also mapkey(M), mkfontdir(X), rgb(X), scologin(X), X(X), xauth(X), xhost(X), xmodmap(X), xsconfig(X), xset(X), xswkey(X)