1    X Window System Administration in the Tru64 UNIX Environment

This chapter provides information about administering the X Window System environment for systems running the Tru64 UNIX operating software. The X Window System Administrator's Guide (O'Reilly & Associates, Inc.) is included in the Tru64 UNIX hardcopy documentation set as the primary reference for information on how to manage X resources that control the X Window environment. Most of the information in that manual is generally applicable to the Tru64 UNIX implementation of the X Window System.

You should read the O'Reilly manual in conjunction with this manual. Section 1.2 in this manual provides a list of items in the O'Reilly manual that are handled differently or are not supported by the Tru64 UNIX implementation of the X Window System. Although the O'Reilly manuals have not been updated for X11 R6, they are still a valid resource.

This chapter includes information on the following topics:

• Display managers

• Locations of the X Window System files on Tru64 UNIX

• X Display Manager (xdm) and the login process

• Security and xdm authorization

• X Window System login problems

• X server management

• Graphics adapters

• Font server management

• X terminal management

• X server memory utilization

Many of these topics are covered in greater detail in the O'Reilly manual.

1.1    Choosing the xdm or the dtlogin Display Manager

You can configure your system to either the standard X11 R6 display manager xdm or the CDE display manager dtlogin. Run the /usr/sbin/xsetup script to switch between CDE and xdm. The xsetup script sets the value of the /etc/rc.config variable XLOGIN to be xdm or cde and will optionally restart your X display manager using the /sbin/init.d/xlogin script. When your system boots, the /sbin/init.d/xlogin script uses the value of the /etc/rc.config XLOGIN variable to determine whether to start xdm or CDE's dtlogin.

If for any reason you need to restart your X display manager, this can be done using xsetup, whether or not you choose to switch from one display manager to another. Alternatively, the X display manager can be stopped, started, or restarted using the /sbin/init.d/xlogin command with stop, start, or restart specified as the parameter.

For further information on configuring CDE and dtlogin, refer to Common Desktop Environment: User's Guide.

The information in the rest of this chapter primarily applies if you choose to run xdm. While dtlogin is similar to xdm and uses the same methods and concepts, there are important differences in the details.

1.2    Administrator's Guide - Tru64 UNIX Differences

Table 1-1 lists specific sections in the X Window System Administrator's Guide (O'Reilly & Associates, Inc.) where the information does not apply to the Tru64 UNIX X Window System environment. (The differences do not in any way reflect errors or omissions on the part of the authors of that manual.)

Table 1-1:  Tru64 UNIX Implementation-Specific Differences

1.3    Locations of the X Window System Files

The file locations shown in the following list reflect the locations of the X Window System files as established by the workstation installation kits.

1.4    X Display Manager (xdm) and the Login Process

The X Display Manager (xdm) manages user sessions on both local and remote displays. On Tru64 UNIX systems, the xdm utility provides the mechanism for logging in to the X display and then starts certain client applications automatically.

The xdm utility creates child processes for each display both locally and remotely. The xdm utility is an X client that manages user session elements, such as logging in, authentication, and default resource set up. System administrators can use xdm to make systemwide configurations of the X Window System environment.

Figure 1-1 shows the kinds of processes that xdm manages.

Figure 1-1:  The xdm Processes

The xdm daemon starts when the system boots in multiuser mode, so it is ready to manage the login process. The following list shows the steps involved in the login process on Tru64 UNIX systems:

1. The system uses the following command during the booting procedure to start the xdm daemon:

   /sbin/init.d/xlogin start
    
   

   On Tru64 UNIX systems, the xdm daemon is started by an initialization script that is run using the following link:

   /sbin/rc3.d/S95xlogin -> ../init.d/xlogin
   

2. The xdm program reads its main configuration file:

   /usr/var/X11/xdm/xdm-config
   

3. The xdm program listens on its socket for requests from any X terminals.

4. The xdm program forks a child process for managing the local display.

5. The xdm program displays the login box (login widget) on the local display. For this procedure, xdm executes the following steps:

   1. Secures the display.

   2. Loads Xresources from the X server resource database utility xrdb. Loading the resources sets the display characteristics for the xdm login box.

   3. Runs the Xsetup_0 setup script on the local display.

   4. Displays the login box (login widget) on the local display.

6. The user enters his or her name and password in the login box. User authentication takes place ensures that the user is allowed to access this display.

7. The login widget is destroyed and xdm runs the GiveConsole startup script on the local display using the root uid.

8. The X session starts up as a child process using the user's id (uid). The startup action involves executing the /var/X11/xdm/Xsession script which either runs the user's $HOME/.xsession script or dxsession.

9. The user exits the session.

10. The xdm program runs the /var/X11/xdm/TakeConsole script on the local display using root's uid.

11. The xdm local display process exits. At this point the workstation returns to the state it was in at step 4, where xdm forks a child process for managing the local display and displays the login widget. The workstation is ready for a user to log in.

On Tru64 UNIX, the /var/X11/xdm directory contains the following files:

• GiveConsole

  This script is run when xdm starts up and changes the ownership of the console, /dev/console, from root to the user. The script only runs on the local display. (It cannot be used with X terminals.)

• TakeConsole

  This script is run when xdm is reset and returns ownership of the console, /dev/console, from the user to root. The script only runs on the local display. (It cannot be used with X terminals.)

• Xaccess

  This configuration file controls how xdm responds to different queries from the X Display Manager Control Protocol (XDMCP). This file is used to manage X terminals.

• Xkeymaps

  This file defines the mapping between language and keyboard and the corresponding keymap file in the /usr/lib/X11/keymaps directory. Whenever the server is started or reset, the keymap is loaded into the X server by xdm using the xmodmap command.

  The value of the console language variable and the keyboard type are retrieved from the kernel and used as an index into the Xkeymaps table to define the appropriate keymap.

• Xresources

  This file contains resource specifications that are loaded into the X server's resource database, xrdb, before the login widget is displayed. These resources affect the appearance of the login window and screen (either dxlogin or xlogin), the background color of all clients, as well as the appearance of the clients which are started by xdm: xconsole, dxconsole, and chooser .

  The dxlogin resources can control the following elements:

  • Digital logo pixmap, clipmask, foreground color, background color, and login box position

  • Root window color

  • Greeting text, font, and color

  • Prompt text as well as color and font for both the prompt and answer

  The default background color for all clients is #ca94aa469193, which is a light tan.

• Xservers

  This file defines the command that starts the server on the local display. More entries for workstations or X terminals can be added as needed.

  The default definition for the UNIX socket transport (DISPLAY :0) is:

  :0 local /usr/bin/X11/X
  

  The default definition for the Shared Memory Transport (SMT) (DISPLAY local:0) is:

  local:0 local /usr/bin/X11/X
   
  

  This file can also be used to specify entries for X terminals that do not support XDMCP.

• Xservers.fs

  The file is read by file server systems that use the xdm-config.fs configuration file. This file is used to specify entries for X terminals that do not support XDMCP.

• Xsession

  This initial startup script is executed under the user's uid to run the login session. If a $HOME/.xsession script is available, it runs. Otherwise, xdm runs the default session, dxsession, which is the DECwindows Session Manager.

• Xsetup_0

  This script is used only to configure the local X server; it cannot be used with remote X terminals. The script attempts to determine the display resolution and uses that information to set the appropriate font path. It also starts dxconsole, unless an alternate console is being used.

• keymap_default

  The xdm program links to the appropriate keymap file in /usr/lib/X11/keymaps.

• xdm-config

  This configuration file contains the values for a number of DisplayManager resources.

• xdm-config.fs

  This version of the xdm_config file is for use by server systems that do not have a local graphics display.

• xdm-errors

  This file is an error log file. Both xdm and the X server write all error messages to this file.

• xdm-pid

  Once this file records the xdm process id, it is locked to prevent multiple invocations of xdm.

The following files are the default and alternate greeter modules. They are located in the /usr/shlib/X11 directory:

libXdmDecGreet.so

libXdmGreet.so

The greeter module presents the login interface and authenticates the user and is dynamically loaded by xdm. The libXdmDecGreet.so file uses OSF/Motif-style widgets. The libXdmGreet.so file uses Athena-style widgets.

The OSF/Motif-style greeter is the default. It displays the Digital logo and login box. It uses the Security Integration Architecture (SIA) to provide improved security.

The Athena-style greeter uses the standard X Consortium graphical user interface (GUI). It does not use SIA and therefore cannot be used with enhanced C2 security.

1.5    Security and xdm Authorization

Because the X Window System runs in a networked environment, any other host on the network can access individual workstation unless some kind of security mechanism is in place. The X Window System design makes it possible for any client that is able to connect to a workstation's X server to have complete control over that workstation's display. As a result, a client can take control of the mouse or keyboard, send keystrokes to any application running on the workstation, or kill windows in which other applications are running.

This section presents a summary of the X security environment. Refer to the X Window System Administrator's Guide for details about implementing X security mechanisms for your system.

There are two approaches to X Window System security: host-based security and user-based security. The following sections briefly discuss each type.

1.5.1    Host-Based Security

With host-based access control, only local clients are accepted by default. X Window System administrators can use the /usr/bin/X11/xhost client application to add or delete host names as well as user names from a list of those allowed to connect to the X server. The xhost program uses host names to limit host connections. Therefore, there is no security among users on an individual host; only security among hosts.

Another host-based security mechanism involves using the /etc/Xn.hosts file to list systems that can access the local server, specified by n. However, this method is not recommended because it is hard to maintain a truly limited list of hosts if more than one user has access to the workstation where the list resides and because the method allows access to the X server at any time, even when the xdm login window appears.

1.5.2    User-Based Security

Tru64 UNIX supports two types of user-based X access control authorization mechanisms: MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1.

The xdm-config resources DisplayManager.DISPLAY.authorize and DisplayManager.DISPLAY.authName control whether xdm uses authorization for local displays. X terminals using XDMCP negotiate with xdm to determine which mechanism to use.

When both the host workstation and the X server are configured to use MIT-MAGIC-COOKIE-1 or XDM_AUTHORIZATION-1, a machine-readable code is placed in the ~/Xauthority file in your home directory every time you log in under xdm control. The term used for this machine-readable code is the magic cookie. The X server is informed of the same magic cookie for the current session. The code is stored in a file in the /usr/lib/X11/xdm/ directory, which the X server reads using its -auth capability.

Whenever a client application starts, it must supply the correct magic cookie code from the ~/Xauthority file to the X server to open the display. Since the permissions on this file are restricted to read/write for the user, only clients that the user starts have permission to read the magic cookie code. The assumption is that if the user starts the client application, he or she wants that application to have permission to run on the user's workstation.

You can use the xauth program to propagate the magic cookie code from one host to another. This feature allows users to run client applications on other workstations that do not share their home directory.

1.6    Solving X Window System Login Problems

This section describes some useful techniques for solving problems you might encounter when trying to log in to the X Window System environment. The first section discusses possible causes for login problems. The second section describes using the failsafe mode to correct various login problems.

1.6.1    Login Problems

If you cannot log in at all to your workstation, you should check for errors in the following places:

• $HOME/.xsession-errors

  This file contains errors generated by your own user account.

• /usr/lib/X11/xdm-errors

  This file contains xdm errors that are not limited to your own user account.

The following list describes the most common login problems and likely causes:

• After you enter your name and password in the login box, the screen immediately resets, redisplaying the login box.

  Possible causes for these problems are as follows:

  • There might be errors in the $HOME/.xsession script. For example, if there is an ampersand (&) on the last command line in the file, there would be no controlling process for the X session and the session would exit immediately.

  • If your user disk and /tmp file system are both more than 100% full, you cannot log in because there is no space to write the .Xauthority file.

  • If the /usr/lib/X11/xdm/Xsession script was customized, errors might have been introduced accidentally.

• You are able to log in, but only a single terminal window appears.

  The Xsession script has resorted to failsafe mode. Possible causes are as follows:

  • The user disk is more than 100% full.

  • The user's home directory is not writable.

• No login box appears on the local display and there is no X server.

  If you encounter this problem, check the /usr/lib/X11/xdm-errors file for error messages. Possible causes for these error messages are as follows:

  • There are problems in the /usr/lib/X11/Xserver.conf file.

  • There are problems in the /usr/lib/X11/xdm/xdm-config file or the files that it references.

• You cannot log in to an X display as root.

  For root login to an X display to be allowed, the name of the display must be listed in the /etc/securettys file for your workstation. If the display name is listed in that file, you can log in as root to the X display.

  The /etc/securettys file usually includes the entries :0 and local:0 to allow root login to the local display. You can add entries for remote X terminals or X displays so you can log in remotely as root from those machines.

1.6.2    Failsafe Mode

When you have problems logging in to your workstation, you can use failsafe mode to bring up a terminal window. You can use this terminal window to perform operations that can solve some of the login problems outlined in the previous section. Failsafe mode bypasses the .xsession script and dxsession session manager to display a single dxterm window. You can use this dxterm window to debug your .xsession script.

You can invoke the failsafe mode by pressing the F1 or F2 key after typing your password in the login box. Do not press the Return key.

If you are able to log in, but only a single terminal window appears, you are already in failsafe mode.

Once you are in failsafe mode, you can check the errors in the xdm-errors file; check for errors in the xsession script, Xsession file, Xserver-conf file, or xdm-config file; or delete files if the user disk is full.

1.7    Managing the X Server

The X server consists of components that are all located in dynamically loadable libraries. The libraries are in the following directory:

/usr/shlib/X11

There are libraries for device support as well as others for X server extensions and font renderers. Section 3.1 provides descriptions of the X server extensions that the Tru64 UNIX operating system supports.

You specify which libraries you want loaded in the /usr/var/X11/Xserver.conf resource file.

On Tru64 UNIX systems, the X Window System programming extensions are built and dynamically loaded as sharable libraries. The X protocol requires that client applications must call the XQueryExtension function before using an extension. The XQueryExtension function returns extension information such as the base request number, number of requests, base error number, number of errors, and version string.

With this mechanism in place, the X server can defer loading any extension libraries until a client requests a specific extension. When the X server receives an XQueryExtension protocol request, it loads and initializes the appropriate extension library if that library has not previously been loaded.

In real time, this loading causes a slight delay in processing the first request for an extension library. However, no such delay is experienced during server start up. When the X server is shut down, it closes all libraries that were loaded on demand and returns to its zero state.

The extension library on Tru64 UNIX consists of the following sharable libraries. The first four libraries are loaded at server startup time; the remaining libraries are loaded on demand.

• libxkb.so

• libextshm.so

• libextMultibuf.so

• libextshape.so

• libextMITMisc.so

• libextScrnSvr.so

• libextxtest.so

• libextkme.so

• libextSync.so

• libextXCMisc.so

• libextbigreq.so

• libextxtrap.so

• libdixie.so

• libmixie.so

• libxinput.so

• libdbe.so

• libPcl.so

• libPS.so

• libextAppgroup.so

• libextSecurity.so

• libextXp.so

• libextdpms.so

• libxv.so

• libprinter.so

Example 1-1 shows the default Xserver.conf resource file that Tru64 UNIX provides.

Example 1-1:  Xserver.conf Resource File

 ! Default configuration file for extensible X server
 
! no other sysyem files are needed
! no other core files are needed
!
 
! device <
! >
 
! You can set alternate library search paths here or supplement the
! default path.
! library_path < /newserver/fonts/lib/font:/usr/shlib >
 
! Add a few more extensions
extensions < 
        < extdpms       libextdpms.so           DPMSExtensionInit       DPMS >   
        < dbe   libdbe.so       DbeExtensionInit        DOUBLE-BUFFER >
        < extshape      libextshape.so  ShapeExtensionInit      SHAPE   > 
        < extMultibuf libextMultibuf.so MultibufferExtensionInit Multi-Buffering >
! The KME extension is obsolete functionality that supports lock down
! and latching modifiers.  It has been replaced by the XKB extension
! and is only provided here for interoperability with R5 servers.
        < extkme     libextkme.so    KMEInit Keyboard-Management-Extension >
        < extMITMi   libextMITMisc.  MITMiscExtensionInit MIT-SUNDRY-NONSTANDARD >
        < extScrnSvr libextScrnSvr.so ScreenSaverExtensionInit MIT-SCREEN-SAVER >
        < extSync       libextSync.so   SyncExtensionInit       SYNC >
        < extxtest      libextxtest.so  XTestExtensionInit      XTEST >
        < extbigreq     libextbigreq.so BigReqExtensionInit     BIG-REQUESTS >
        < extXCMisc     libextXCMisc.so XCMiscExtensionInit     XC-MISC >
        ! add the xtrap extension
        < extxtrap      libextxtrap.so  DEC_XTRAPInit   DEC-XTRAP >
 
        ! add the video extension along with device specific handlers
        ! for the TX device
        < xv    libxv.so        XvExtensionInit XVideo
                < _dec_xv_tx lib_dec_xv_tx.so XvropScreenInit PMAG-RO >
                < _dec_xv_tx lib_dec_xv_tx.so XvropScreenInit PMAG-JA >
        >
 
 
        ! add the X imaging extension
!not R6 < _dec_xie      lib_dec_xie.so  Xie3Init        Xie >
        < dixie         libdixie.so     XieInit         XIE
                < mixie libmixie.so >
        >
       ! Load Speedo and Type1 renderers and
! enable communication with a font server
font_renderers <
        < fr_fs         libfr_fs.so     fs_register_fpe_functions >
        < fr_Speedo     libfr_Speedo.so SpeedoRegisterFontFileFunctions >
        < fr_Type1      libfr_Type1.so  Type1RegisterFontFileFunctions >
>
 
! Enable X Input Devices
!input <
!       Dial and Button Box on port /dev/tty01
!       < _dec_xi_pcm   lib_dec_xi_pcm.so       XiPcmInit /dev/tty01 >
!
!       Serial Mouse.  Use the following format for the last parameter:
!
!       device:type:baud:emulate3:chordmid:samplerate:cleardtr:clearrts:core
!
!       where
!
!       device:         The port the device is connectd to.
!                       For example, /dev/tty00.  /dev/tty00 is the
!                       default.
!
!       type:           The mouse type.  It must be one of the following
!                       strings (case does not matter):  microsoft
!                       mousesystems mmseries logitech busmouse mouseman
!                       ps/2 mmhittab.  mousesystems is the default.
 
!       baud:           The baud rate of the mouse.  Mine is 1200, I think
!                       others will do 9600.  1200 is the default.
!
!       emulate3:       Either 0 or 1.  1 means emulate a 3 button mouse
!                       with a 2 button mouse.  This is not implemented yet,
!                       though 0 is the default.
!
!       chordmid:       Either 0 or 1.  Some 3 button mice treat MB2 kind of
!                       whacky.  A value of 1 supports those meesers.  0 is
!                       the default.
!
!       samplerate:     The sample rate of the mouse.  I don't have a mouse
!                       that supports this, so I don't know what it does.
!                       150 is the default.
!
!       cleardtr:       Either 0 or 1.  1 means clear the DTR signal for
!                       the port before using the mouse.  0 is the default.
!
!       clearrts:       Either 0 or 1.  1 means clear the RTS signal for
!                       the port before using the mouse.  0 is the default.
!
!       core:           Either 0 or 1.  1 means make this emulate the core
!                       device.  0 means make it a two relative motion
!                       valuator, n-button X Input Device.  0 isn't
!                       implemented yet.  1 is the default.
!
!< _dec_xi_serial_mouse lib_dec_xi_serial_mouse.so XiSerialMouseInit\
! /dev/tty00:microsoft:1200:1 >
!>
! transport and auth_protocol library loading is not yet supported
 
! you specify command line arguments here
args <
        -pn
>!
 
 
 

The following three Xserver command flags are especially useful in managing the X server. For more complete information on the Tru64 UNIX Xdec and Xserver command, see the Xdec(1X) reference page.

• -terminate

  This flag causes the server to exit rather than to reset.

  You can also achieve the same effect by setting the following xdm resources in the xdm-config file:

  • DisplayManager._0.terminateServer: true

  • DisplayManager.local._0.terminateServer: true

• -edge_left scr1 scr2

• -edge_right scr1 scr2

  You use one of these flags to connect the edges of screens in a multihead display configuration.

• -fp fontpath

  You can use this flag to set the default font path. The path consists of a comma-separated list of directories for the X server to search to find the font databases. Make sure that all components of the list are valid font directories or else the X server will exit.

The X server has been modified to query the kernel automatically for the language and keyboard of the console. Given this information, the X server will examine the contents of the /usr/lib/X11/xkb/keymaps.dir file to determine which default keymap to use. The X server will then compile the keymap, place the compiled version in the directory /usr/lib/X11/xkb/compiled, and load it. This feature has been enabled by default. To disable it, add the -noloadxkb switch to the command line. If you wish to disable the XKB extension altogether, add the -kb switch to the command line. See the Xdec(1X) reference page or run Xdec with the -? option for more information.

1.8    Graphics Adapters

This section lists many of the graphics adapters supported by Tru64 UNIX. (Absence of any adapter from this list does not necessarily mean that the adapter is not supported.) Some graphics adapters require the DEC Open3D software product for full three-dimensional support.

In addition, the X Window System environment on Tru64 UNIX supports the following monitors:

VRT16-HA/H4 16" 66/72HZ 1280x1024

VRT19-HA/H4 19" 66/72HZ 1280x1024

VRM17-HA/H4 17" 72HZ 1280x1024

VR319-DA/D4 19" 72HZ 1280x1024

VR320-Dx 19" 72HZ 1280x1024

VR320-Cx 19" 66HZ 1280x1024

VR160-Dx 16" 60HZ 1280x1024

VR297-Dx 19" 60HZ 1024x864

VR290-x 19" 60HZ 1024x864

VR299-Dx 19" 60HZ 1024x864

VRC16-Cx 17" 72HZ 1024x768

1.9    Font Server Management

In Tru64 UNIX, /usr/bin/X11/xfs is the X Window System font server. The font server supplies fonts to the X Window System display servers.

For X11 R6, the font server was renamed from fs to xfs. For compatibility, the symbolic link/usr/bin/X11/fs --> xfs is provided on Tru64 UNIX. Most X11 R5 and X11 R6 X servers can communicate with a font server. For example, Digital VXT V2.1 X terminals can communicate with the font server in the Tru64 UNIX operating system.

For Tru64 UNIX, the font server loads the following configuration file by default:

/var/X11/fs/config
 

Example 1-2 shows the default configuration file. Note that on the Tru64 UNIX system, the catalogues and renderers lines are not separated as shown in the example.

Example 1-2:  Font Server config File

# font server configuration file
# $XConsortium: config.cpp,v 1.7 91/08/22 11:39:59 rws Exp $
 
clone-self = on
use-syslog = off
catalogue = /usr/lib/X11/fonts/decwin/100dpi/,
            /usr/lib/X11/fonts/decwin/75dpi/,
            /usr/lib/X11/fonts/misc/,
            /usr/lib/X11/fonts/75dpi/,
            /usr/lib/X11/fonts/100dpi/,
            /usr/var/X11/fonts/user/misc/,
            /usr/var/X11/fonts/user/100dpi/,
            /usr/var/X11/fonts/user/75dpi/
error-file = /usr/var/X11/fs/fs-errors
# in decipoints
default-point-size = 120
default-resolutions = 75,75,100,100
renderers = libfr_Type1.so;
            Type1RegisterFontFileFunctions,libfr_Speedo.so;
            SpeedoRegisterFontFileFunctions

The following list explains the elements in the file:

• clone-self

  This line indicates whether the font server should try to clone itself or use delegates when it reaches the limit for number of clients. By default, the Tru64 UNIX font server clones itself when the limit is reached.

• use-syslog

  This line indicates whether or not syslog() is used for font server error logging. For Tru64 UNIX, the value is set to off, which means that, by default, errors are logged to the error-file specified in this configuration file.

• catalogue

  This line contains the list of font directories that are available by default from the Tru64 UNIX font server.

• error-file

  This line lists the path name of the error log file. This file is used instead of syslog(). If you encounter problems after you have modified the configuration file, check the /usr/lib/X11/fs/fs-errors log file to debug your changes.

• default-point-size

  This line indicates the default point size for any font request that does not specify a point size. Note that the point size is specified in decipoints, so that a value of 120 indicates a point size of 12.

• default-resolutions

  This line lists the default resolutions supported by the Tru64 UNIX font server. The values are given in pairs of horizontal and vertical resolutions per inch.

• renderers

  This line defines the dynamically loaded renderer libraries for scalable fonts. These renderer libraries are the same font renderer libraries that can be loaded by the X server.

1.9.1    Using the Font Server

To use the font server, you need to add the appropriate port to your font path. For Tru64 UNIX, the default port number is 7100. The default port number is the registered port 7100. (Note that many R5 implementations used port 7000 which was not registered. Use the following syntax to add the font server to your font path:

xset +fp tcp/hostname:7100

Replace the hostname variable with the name of the system where the font server is running.

You can create a script that automatically starts the font server when you boot your system in multiuser mode. Add a symbolic link to your script in /sbin/rc3.d. For example:

/sbin/rc3.d/S94fs -> ../init.d/fs
 

For more details, see the rc3(8) reference page.

The following example shows a sample font server initialization script:

#!/sbin/sh
PATH=/sbin:/usr/sbin:/usr/bin
export PATH
#
# Control X font server
#
case $1 in
 
\'start\')
    if [ -f /usr/bin/X11/xfs ]
    then
      /usr/bin/X11/fs -config /usr/lib/X11/fs/config -port 7100
&
    else
        echo "WARNING: Font server not found."
        exit 1
    fi
    ;;
\'restart\')
 
 $0 stop
 sleep 5
 $0 start
    ;;
\'stop\')
    pid=`/bin/ps -e | grep '/usr/bin/X11/fs' |
        sed -e 's/^  *//' -e 's/ .*//' | head -1`
    if [ "X$pid" != "X" ]
    then
        /bin/kill $pid
    fi
    ;;
esac

1.9.2    Font Server Client Utility Applications

Tru64 UNIX includes several font server client utilities: fsinfo, fslsfonts, fstobdf, and showfont. The following list shows how to invoke each utility and provides a brief description. See the reference page for each utility for more information.

• fsinfo

  The fsinfo utility displays information about an X font server. You can use it to examine the capabilities of the server currently running on your system. The display shows predefined values for various parameters that are used for communication between clients and the server. The display also lists the font catalogues and alternate servers that are available.

  The following example shows the default fsinfo display for a Tru64 UNIX system named COFFEE:

  
  % fsinfo -server tcp/coffee:7100
  name of server: tcp/coffee:7100
  version number: 2
  vendor string: Digital Equipment Corporation Tru64 UNIX V4.0
  vendor release number: 5001
  maximum request size: 16384 longwords (131072 bytes)
  number of catalogues: 1
           all
  Number of alternate servers: 0
  number of extensions: 0
  

• fslsfonts

  You can use the fslsfonts utility to display a list of all the fonts served by the current font server. The following example shows a partial display for the default Tru64 UNIX font server on a system named COFFEE:

  % fslsfonts -server tcp/coffee:7100
  adobe-avantgarde-demi-i-normal--0-0-0-0-p-0-iso8859-1
  adobe-avantgarde-demi-r-normal--0-0-0-0-p-0-iso8859-1
  adobe-avantgarde-medium-i-normal--0-0-0-0-p-0-iso8859-1
  adobe-avantgarde-medium-r-normal--0-0-0-0-p-0-iso8859-1
  adobe-courier-bold-i-normal--0-0-0-0-p-0-iso8859-1
       .
       .
       .
  

  You can also use the fslsfonts utility to list the fonts that match a specified pattern. See the fslsfonts(1X) reference page for details.

• fstobdf

  The fstobdf utility reads a font from the font server and creates a BDF (bitmap distribution format) file on the standard output that can be used to recreate the font. You can use this utility to test font servers, debug font metrics, and reproduce lost BDF files. However, you should be careful not to violate any copyrights or licensing agreements that pertain to the fonts.

  The following command invokes the utility to create a BDF file for a bold font using the font server on system COFFEE:

  
  % fstobdf -server tcp/coffee:7100 -fn "*bold*" > boldfont.bdf
  

• showfont

  You can use the showfont utility to display information about a particular font that is served by the current font server.

  Each of the following commands invokes the utility to display information about the Adobe Avantgarde Demi font available from the font server on system COFFEE:

  % showfont -server tcp/coffee:7100 -fn\ 
  "-adobe-avantgarde-demi-*-*--*-*-*-*-*-*-*-*" 
  % showfont -server tcp/coffee:7100 -fn\ 
  "-adobe-avantgarde-demi-r-normal--0-0-0-0-p-0-iso8859-1" 
  

1.10    Managing X Terminals

Like workstations, X terminals have monitors, pointers, and keyboards but otherwise they resemble dumb ASCII terminals because they need to be connected to a host computer to function. In most instances, the X terminal reads the X server program at boot time from the host system over the network. However, there are some X terminals that also have the X server built directly into the terminal's read-only memory (ROM).

For X terminals that have X11 R4, R5, or R6 installed, host systems use the X Display Manager (xdm) and the X Display Manager Control Protocol (XDMCP) to serve those terminals. X11 R5 or X11 R6 have many more capabilities and are therefore preferable if you are considering purchasing new X terminals.

There are three types of XDMCP queries that an X11 R4, R5, or R6 terminal can use to connect to a host:

• Direct

  With a direct query, the X terminal requests a login from only one host. The xdm program on the host responds and displays the login window.

• Indirect

  With an indirect query, depending on the host's Xaccess file, xdm either forwards the query to another host or displays the chooser box, which contains a list of available host nodes. If the chooser box is displayed, the user selects a host. Next, the chooser client forwards the query to that host. In either case, the second host then displays the login window.

• Broadcast

  With a broadcast query, the X terminal requests a response from any xdm host on the subnet. The X terminal can either request a direct connection to the first xdm host that responds or collect responses for a period of time and offer the list to the user to select one.

Once the connection between the X terminal and the host has been made, the user has access to all the X Window System features that are available on the host system.

You specify access control for XDMCP connections to X terminals in the /usr/lib/X11/Xaccess file. This file is defined in the xdm-config file by the DisplayManager.accessFile resource. The following list contains examples of different types of connection queries:

• Direct or broadcast queries

  # disallow direct/broadcast service for xtra
  !xtra.lcs.mit.edu
   
  # allow access from this particular display
  mars.osf.org
   
  # allow access from any display in LCS
  *.lcs.dec.com
  

• Indirect queries

  %HOSTS expo.lcs.dec.com xenon.lcs.dec.com \
  excess.lcs.dec.com kanga.lcs.dec.com
   
  # force extract to contact xenon
  extract.lcs.dec.com xenon.lcs.dec.com
   
  # disallow indirect access
  !xtra.lcs.dec.com dummy
   
  # all others get to choose
  *.lcs.dec.com %HOSTS
  

• Indirect queries from the chooser

  # offer a menu of these hosts
  extract.lcs.dec.com CHOOSER %HOSTS
   
  # offer a menu of all hosts
  xtra.lcs.dec.com CHOOSER BROADCAST
   
  # offer any host a menu of all hosts
  * CHOOSER BROADCAST
  

Older X terminals with X11 R3 can be managed directly without XDMCP. To use these X terminals, you must include a specific entry in the /var/X11/xdm/Xserver file. For example, to manage an X terminal named CREAM, include the following line in the Xservers file:

cream:0 foreign

With such a connection, the xdm utility immediately displays a login window on the X terminal.

1.11    Memory Utilization by the X Server

Under normal operating conditions, the X server requires large amounts of memory. Once memory is allocated to the X server, it is never freed to the system. It can be reused, but never freed. This means that the X server memory allocation may increase dramatically at startup and then become fairly stable, unless you continue to start new and unique client applications without terminating any of the earlier applications.