Using XSettings

You can start XSettings by double-clicking on the XSettings icon in the WinaXe Plus Programs' folder:

The XSettings dialog box will appear on your display. It consists of 7 tabs described below.

By clicking OK, any new settings you make to the XSettings dialog box will be saved in the "[XSETUP]" section of the xwp.ini file (by default) and the dialog will be closed. (See also section Running XSettings with Command Line Parameters.)

On how to port XServer's settings (i.e., the "[XSETUP]" section of the ini-file) onto other PCs, see subsection Exporting XServer's Settings During Installation in section Running Setup in chapter Installing WinaXe Plus.

You can cancel any changes you have made to the dialog box and close it by pressing Cancel.

The Startup Tab

The Window Mode List

This item allows you to make a choice of the XServer startup mode. Select a desired window mode by clicking on a mode name. (For more information, see related sections in Chapter Using XServer.)

• Multiple

  In this mode, MS Windows works as a local window manager for your X clients. When an X client starts, it appears in a window like any other displayed by MS Windows. Each client you start creates its own window on your display. The client window's controls (i.e. its borders, the Control Menu box, move window functions, etc.) are all handled by MS Windows on your PC.

• Single

  This mode presents all X clients in a single X-session window. Within the window, the window management and all other functions are typically controlled by an X Window System manager you start on a host. The X-session window itself can be sized and moved like any other MS Windows window.

• Full Screen

  This mode presents all X clients in a single root window taking up full the screen outside the MS Windows graphical environment. The window management and all other functions are typically controlled by an X Window System window manager you start on a host.

• Multiple+RemoteWM

  This mode is the above Multiple mode, but the local MS Windows window manager does not control windows of X clients and a user has to run any suitable remote window manager. The mode is very convenient when users use CDE-like interface where a remote window manager provides its own tool/task bar.

The Use XDMCP Box

X Display Manager Control Protocol (XDMCP) is a popular method of starting remote login sessions. Once XServer configured to use XDMCP has initiated X-session for the first time, it contacts an 'xdm' process running on a host system.

XDMCP settings are used to control the XDMCP startup method. The Use XDMCP check box lets you specify the XDMCP settings.

Change XDMCP settings only after consulting with your system administrator.

The XDMCP Mode Box

You can check one of the following XDMCP modes:

• Query

  In this mode, a particular host used to establish the X connection must be specified in the Connect Host field.

• Broadcast

  This mode does not allow you to specify a host in the Connect Host field. Instead, XServer will broadcast a request to start the X connection to every host named in the Broadcast List File.
  To use this mode, you must create a Broadcast List File.

  If you select the Broadcast mode, then the Select XDMCP Host window will appear after loading XServer. In this window, you will see the XDMCP hosts running on your network, and you can select one of them to start the X-session.

• Indirect

  The query will be sent to the host specified in the Connect Host field. Then this host will either start up or broadcast a request for one or more other hosts to start the X connection.

Connect Host

This field is used to specify a network node name or IP address for the host you want to connect to in the Query or Indirect startup mode.

When you click on the scroll arrow beside the Connect Host box, a drop-down box will display host definitions listed in your hosts file. To select a host, just click on an appropriate definition.

If the hosts file does not contain the host definition you need, you can enter the host's IP address in the field (in the standard dotted IP address notation).

Broadcast List File

In the Broadcast startup mode, specify a file that contains a list of hosts that your PC will transmit a 'broadcast' message to.

The file consists of text lines each of the following format:

IP_address comment
or
name comment

Names must be specified as official host names or aliases in your hostsfile. Note that the syntax allows you to use the hosts file as the Broadcast List File.

Note: if you leave this field empty or enter either 0.0.0.0 or 255.255.255.255 (these special destination addresses specify a broadcast), then this will provide the XDMCP broadcast mode (when your PC will transmit a 'broadcast' message to every host on your local network to query all XDMCP daemons).

Reset XServer at XDMCP Close

If checked, this check box enables closing all X clients if the remote XDM daemon terminates the XDMCP session with XServer.

XDM/CDE Special Processing

Check this check box if you are going to use the CDE XDMCP mode, i.e. with CDE installed on the remote XDMCP host (for the XServer's Multiple window mode only).

XDM Authentication/Authorization

This check box allows you to enable the XDM-AUTHENTICATION-1 and XDM-AUTHORIZATION-1 schemes. If your host is using XDM authentication or XDM authorization scheme, set up the values in the Display ID, Display Class, and Key fields and report them to your system administrator.

If you disable XDM authentication/authorization, then XServer will use the default client authorization scheme, MIT-MAGIC-COOKIE-1.

Notes:

According to the XSECURITY manual page of X Window System, X provides mechanism for implementing many access control systems. The sample implementation includes some mechanisms with MIT-MAGIC-COOKIE-1 (using shared plain-text "cookies") and XDM-AUTHORIZATION-1 (using secure DES-based private-keys) being two of them.

• MIT-MAGIC-COOKIE-1

  When using MIT-MAGIC-COOKIE-1, the client sends a 128-bit "cookie" along with the connection setup information. If the cookie presented by the client matches one that the X server has, the connection is allowed access. The cookie is chosen so that it is hard to guess; xdm generates such cookies automatically when this form of access control is used. The user's copy of the cookie is usually stored in the .Xauthority file in the home directory, although the environment variable XAUTHORITY can be used to specify an alternate location. Xdm automatically passes a cookie to the server for each new login session, and stores the cookie in the user file at login.

  The cookie is transmitted on the network without encryption, so there is nothing to prevent a network snooper from obtaining the data and using it to gain access to the X server. This system is useful in an environment where many users are running applications on the same machine and want to avoid interference from each other, with the caveat that this control is only as good as the access control to the physical network. In environments where network-level snooping is difficult, this system can work reasonably well.

  This system uses 128 bits of data shared between the user and the X server. Any collection of bits can be used. Xdm generates these keys using a cryptographically secure pseudo random number generator, and so the key to the next session cannot be computed from the current session key.

• XDM-AUTHORIZATION-1

  Sites in the United States can use a DES-based access control mechanism called XDM-AUTHORIZATION-1. It is similar in usage to MIT-MAGIC-COOKIE-1 in that a key is stored in the .Xauthority file and is shared with the X server. However, this key consists of two parts - a 56-bit DES encryption key and 64 bits of random data used as the authenticator.

  When connecting to the X server, the application generates 192 bits of data by combining the current time in seconds (since 00:00 1/1/1970 GMT) along with 48 bits of "identifier". For TCP/IP connections, the identifier is the address plus port number; for local connections it is the process ID and 32 bits to form a unique id (in case multiple connections to the same server are made from a single process). This 192-bit packet is then encrypted using the DES key and sent to the X server, which is able to verify if the requestor is authorized to connect by decrypting with the same DES key and validating the authenticator and additional data. This system is useful in many environments where host-based access control is inappropriate and where network security cannot be ensured.

  This system uses two pieces of information. First, 64 bits of random data, second a 56-bit DES encryption key (again, random data) stored in 8 bytes, the last byte of which is ignored. Xdm generates these keys using the same random number generator as is used for MIT-MAGIC-COOKIE-1.

Default

This button sets up the default values for check boxes and edit fields in the Use XDMCP box.

The XDM Authentication/Authorization Parameters Box

Display ID

If XDM authentication or XDM authorization has been enabled on the XDM host, your system administrator will need to know the value displayed in this field. This field should normally never be changed. The Display ID value consists of these two parts separated by hyphen: the Display Class value and the arbitrary numerical value.

In very rare cases, your system administrator may determine that your Display ID is a duplicate and will ask you to generate a new one. To do this, use arrows on the right side of the Display ID field. The up arrow increases the numerical value of the Display ID, and the down arrow decreases it.
Do not do this without consulting with your administrator.

Display Class

This field can be used to group classes of XDM nodes. The field should only be modified at the request of your system administrator. Otherwise it should be left unchanged.

Key

This field defines the key used in XDM authentication. If your host is using XDM authentication, your system manager will need to know the contents of your XDMCP Key and Display ID fields. This field should only be modified at the request of your system administrator. Otherwise it should be left unchanged.

The Mouse_Keyboard Tab

The Mouse Settings Box

Middle Button Emulation

The default setting specifies a two-button mouse with the check box enabled. If you are using a 3-button mouse, click to disable the check box. The middle mouse button is emulated by clicking simultaneously both left and right mouse buttons.

Use Mouse Wheel

This check box enables/disables XServer to process the mouse wheel (i.e., to translate its rotation to the Button4 and Button5 press/release X-events).

Note that the mouse wheel does not take effect in the non-maximized Single Window mode (because of Scrollbars).

The Keyboard Settings Box

Keyboard File List

You can configure XServer to support different international PC keyboards. The package supplies a set of keyboard mapping files that define assignments of key functions to physical keys on appropriate keyboards. The files are listed in Appendix A.

You can enter any kmf-file name in the edit field or select an appropriate keyboard file from the Keyboard File List by clicking on its file name. The default keyboard file is us.kmf.

For more information, see section Keyboard Definition Files in chapter The WinaXe Plus Database.

Local NumLock Key

If this check box is enabled, XServer (not X clients) will process the NumLock key.

Unlatched NumLock

If this check box is enabled, XServer will consider the NumLock key as a normal key (non-toggling). The NumLock key is unlatched by default. This was implemented to suppress the NumLock state's influence on some X Window managers and programs.

Local ScrollLock Key

This is important only for the XServer's Full Screen mode. The key is used for iconifying the XServer's window. If this check box is enabled, XServer (not X clients) will process the ScrollLock key.

Unlatched ScrollLock

If this check box is enabled, XServer will consider the ScrollLock key as a normal key (non-toggling). The ScrollLock key is unlatched by default.

Block KeySyms Changing

If enabled, this check box prevents the XServer keyboard's KeySyms mapping from external changes (e.g., by the "xmodmap" utility). The default is On.

Block Modifiers Changing

If enabled, this check box prevents the XServer keyboard's Modifiers mapping from external changes (e.g., by the "xmodmap" utility). The default is On.

Keyboard Mapping for Linux

If this check box is enabled, XServer will provide a "close-to-Linux" keyboard mapping (i.e., the Linux console keyboard mapping). This setting would be useful when using some applications of the KDE 3.x package (e.g., the "kwrite" editor) that do not correctly recognize some keys (e.g., "Shift+arrows" key combinations).

Default

This button sets up the default values for check boxes and edit fields in the tab.

The Screen Tab

The Screen Settings Box

Enable Animation

If checked, this check box causes XServer to more precisely display color images.

Local Screen Saver

If enabled, this check box causes a Local Screen Saver program to be run (for the XServer's Full Screen and Single modes only).

Forced Backing Store

This option can be used if the Backing Store mode is enabled. (See the Advanced Tab.)

If this check box is checked, the Backing Store mode will be used with all X clients. The option will cause XServer to use Backing Store on all windows, even if the X-application does not request it.

Certain X-applications will request the Backing Store mode on windows that are complicated to draw. If this check box is clear, XServer will only use Backing Store on those windows that the X-application does request it.

Enable RENDER Extension

This option enables XServer to use the RENDER extension (not available in the 8-bits X depth mode). This also provides a wider range of available pixmap depths.

Color Mouse Cursor

If this check box is checked, then XServer is allowed to use the color mouse cursor when X clients use it.

The Display Number Box

Display Number

You can specify a display number for a particular X-session. This allows you to run simultaneously several X-sessions, each with different Display Number (e.g., several Window Managers). Section Running Several X-sessions in chapter Using XServer describes examples of using the Display Number setting.

According to X11 documentation, from the user's prospective, every X server has a display name of the form: hostname:displaynumber.screennumber .This information is used by the application to determine how it should connect to the server and which screen it should use by default (on displays with multiple monitors).

The hostname specifies the name of the machine to which the display is physically connected. For the TCP/IP type of connections, the hostname part of the display name should be the server machine's IP address name. Full Internet names, abbreviated names, and IP addresses are all allowed.

The phrase DisplayNumber is usually used to refer to collection of monitors that share a common keyboard and pointer (mouse, tablet, etc.). Most workstations tend to only have one keyboard, and therefore, only one display. Larger, multi-user systems, however, frequently have several displays so that more than one person can be doing graphics work at once. To avoid confusion, each display on a machine is assigned a display number (beginning at 0) when the X server for that display is started. The display number must always be given in a display name.

Some displays share a single keyboard and pointer among two or more monitors. Since each monitor has its own set of windows, each screen is assigned a screen number (beginning at 0) when the X server for that display is started. If the screen number is not given, screen 0 will be used.

Each Display Number corresponds to the known Port Number of XServer (0-6000, 1-6001, etc.).

Note that output log files for different Display Numbers have different names, xserver[N].out, with N being Display Number.

Auto

This check box enabled activates XServer to dynamically generate Display Number.

In this mode, any new X-session will have new Display Number and a lot of XServer instances (X-sessions) can be started with no changes in the ini-file. This feature is especially useful with NT/2000 Terminal Servers.

Note: no XServer instances must use equal Display Numbers when running simultaneously on your system (even for different users).

The Virtual Root Size Box

When you select either Single or Full Screen modes for XServer, you can fill in the Width and Height fields. This lets you set the default size in pixels for the XServer's root window. You can make the virtual screen size larger than your display if you want to (e.g., for multi-monitor systems).

The maximum virtual root size is limited by the expression of "width*height sq. pixels <= 56Mbyte" pixels.

Fit to Screen Size

If selected, this check box allows you to skip input for virtual Width and Height. XServer will use the values returned by the MS Windows display driver for a single display.

If this check box is clear, you can specify the Width and Height fields as the default size in pixels that XServer will use for its root window.

If the Width and/or Height fields are zero or negative values, then the actual screen size will be the sum of the value and the corresponding dimension of the PC's screen. For Multiple and Multiple+RWM modes, the "0" and "-1" values are only allowed.

The X depth (bits per pixel) Box

These radio buttons let you choose the color depth and visual mode that XServer will use:
- 8-bit or 256-color visual mode (up to 256 colors);
- 16-bit or HiColor visual mode (up to 65536 or 32768 colors);
- 24-bit or TrueColor visual mode (up to 16777216 colors).

The Auto choice causes XServer to use current video settings of MS Windows (except for 32-bit, in which case XServer can use up to the 24-bit mode).

Note: if MS Windows is set up to the 8-bit visual mode (256 colors), then XServer will use the same mode.

The FullScreen Mode Box

• Minimize on Activity Losing

  If this check box is enabled, the XServer's window will be iconified each time the focus changes to another window. Otherwise, it can be obscured by other windows.

The Image Format Box

• LSB

  This sets up the Image Format to the LSB (Least Significant Byte/Bit first) mode (when every X client must work with XServer using imageByte- and bitmapBit- orders in the LSB format; e.g., X clients on Intel-platform machines).

  This is the default setting (since XServer works with X clients without Image Format conversion).

• MSB

  This sets up the Image Format to the MSB (Most Significant Byte/Bit first) mode (when every X client must work with XServer using imageByte- and bitmapBit- orders in the MSB format; e.g., X clients on SUN workstations).

• Auto

  This specifies that X clients will define the Image Format for XServer.

Default

This button sets up the default values for check boxes and edit fields in the tab.

The GLX Extension Box

The GLX Extension check box enables XServer to work with X clients that use OpenGL.

XServer can work with a number of X clients simultaneously (in a multi-thread mode of GLX), and X clients may create several GLX windows.

Use Single Buffer

This button allows XServer and X clients to use one buffer for GLX operations (the GLX Single-Buffer mode).

Use Double Buffer

This button allows XServer and X clients to use two buffers for GLX operations (the GLX Double-Buffer mode). This is the default mode.

Use Mesa Emulation

This check box allows XServer and X clients to use Mesa.

Use the Mesa Emulation mode together with the Enable RENDER Extension check box selected.

Mesa is an open-source implementation of the OpenGL specification. OpenGL is a programming library for writing interactive 3D applications. Mesa 5.x supports the OpenGL 1.4 specification. Mesa is used as the core of the open-source XFree86/DRI hardware drivers. Mesa allows OpenGL to be used on systems that have no other OpenGL solution. See www.mesa3d.org for more information.

The Font Control Tab

This tab allows you to manage font sources that can be used in X-sessions and to specify how XServer will use fonts in X-sessions.

The Font Manager item in the XServer's Run menu allows you to see: actual Font Path; the font list of each font directory; font information, properties, metrics, and images of any available font. (See section Font Service in chapter Font Control.)

Enable Scaled Fonts

If this check box is checked, then it allows XServer to use scaled fonts.

Trace Fonts Requests

If this check box is checked, then all font requests from X clients (with resolve messages) will be stored in the xserver.out file. This option is useful for analysis of the font accessibility and resolving font problems by XServer.

Default

This button sets up the default values for check boxes and edit fields in the tab.

The Font Search Path Box

Font Directory

A font directory contains a number of font description files in the X11 format. Setup installs a set of font directories under the FONTS subdirectory in the WinaXe Plus home directory (by default).

Any font directory must have the fonts.dir file (that contains the font description list according to font files of the directory), the fonts.ali file (with font aliases), and a set of font description files (with the .pcf, .snf, or .pgz file name extension).

XServer must have access at least to the fixed and cursor fonts. The \FONTS\MINIMAL and \FONTS\MISC font subdirectories contain them. So Font Path must contain these font directories at least.

See section Font Directory in chapter Font Control for more details.

Font Server

You can specify that you want to use a font server running on one or more hosts. Font servers are defined in the X11 R6 release of the X Window System. Instead of forcing XServer to read all fonts from your PC, the X FontServer Protocol makes it possible to manage fonts separately from XServer, directing XServer to request fonts from a font server via the X Consortium standard network protocol. In addition, for fonts that take a long time to open, this allows XServer to continue with other clients while the font server services the font requests.

For example, the following path specifies the font server host called hp9000 on port 7000:

tcp/hp9000:7000

See section Font Server in chapter Font Control for more details.

The Priority ordered path Box

Font Path is an ordered table of font sources (the priority list). A font source is one of the following: a font directory, a reference to a remote font server, and a pseudo font directory. XServer uses Font Path on X client's requests for any font. XServer searches for the required font according to the order of font sources till the first matching occurs.

If you highlight a font path in The Priority ordered path and press OK, then the selected path will appear in the Font directory edit field. You can enter a font directory path in the Font directory edit field or use the Browse button to select it.

Also, see Appendix C Troubleshooting for examples.

Insert before

To insert the Font directory edit field into Font Path, select a path in the Priority ordered path list box and then click the Insert before button.

Insert after

To insert the Font directory edit field into Font Path, select a path in the Priority ordered path list box and then click the Insert after button.

Delete

To remove a highlighted font source from Font Path, press the Delete button.

Cut

To move a highlighted font source from Font Path to the Font directory edit field, press the Cut button.

Pseudo Fonts

If you plan to use MS Windows fonts in an X-session, press the Pseudo fonts button to choose MS Windows fonts and assign aliases to them. This means creating pseudo fonts.

You can compile a pseudo font into the X11 format and save it in any font directory for later use.

You can also create a pseudo font directly in the X-session on particular X client's font requests. To enable this, switch on the Use pseudo fonts and Create pseudo on X client request check boxes in the Pseudo fonts dialog box. Pseudo fonts created in the X-session will only become accessible after restarting XServer.

If you need some X font that is inaccessible, XServer allows you to use any MS Windows font instead of it. MS Windows fonts do not support X11 font naming conventions. Therefore, pseudo names (aliases) are used to access them. To use a MS Windows font, you should create a pseudo font for it, i.e. choose one and assign a desirable alias. Pseudo fonts can be created in advance or immediately in the X-session.

MS Windows font specifications and aliases for Pseudo Fonts are stored in the Pseudo Fonts Directory. The Pseudo Fonts Directory, WINFONTS subdirectory, is located under the WinaXe Plus home directory (by default).

You can manage pseudo fonts by using the Pseudo fonts dialog box.

Creating Pseudo Font

To create a pseudo font, press the Create pseudo button in the Pseudo fonts dialog box. The Font dialog box will appear on your display. Select a suitable font and press OK. In the Specify alias for selected font box, enter a pseudo font alias and click OK.

The created pseudo font will appear in the Select pseudo font list box lexicographically ordered.

The alias must only contain alphanumeric characters (including the 'underscore' sign). The alias must be unique among existing pseudo fonts.

The Save button writes all changes to Pseudo Fonts Directory. This cannot be undone if you press Cancel in the Pseudo fonts dialog box or in the The Font Control Tab afterwards.

Viewing Pseudo Font

To view a pseudo font, select it in the Select pseudo font list box and click the View button. The Font sample window will appear with the font sample in it.

Note that the font image is displayed by the MS Windows (not by XServer). This option is for font identification only.

Deleting Pseudo Font

To delete a pseudo font, highlight it in the Select pseudo font list box and click the Delete pseudo button. You can delete more than one font at a time. You should confirm removing each font and the total number of the selected fonts.

Compiling Pseudo Font to the X11 format

Loading pseudo fonts takes some time to create their images. Reading font image from the X11 format file is faster. It becomes essential if X client uses a lot of fonts. To prevent this time loss, you can save images of frequently used pseudo fonts in the X11-like format in your Pseudo Fonts Directory. This will require some disk space.

To save the image, highlight the required font in the Select pseudo font list box and click the Compile into X11 button. In the Place X11 font to box, specify a font directory to store the X11 font file.

You can enter the font directory path in the Font directory edit field or use the Browse button to select it. If the specified directory is not the font directory (e.g., it is empty), then the fonts.dir file will be created in it.

You should confirm compiling each font. To use the font directory, include it into Font Path.

Creating Pseudo Fonts on X Client Request

Pseudo fonts can be created immediately in the X-session on particular requests of X clients. If the requested font is not found, you will be prompted to create a new pseudo font. Creating pseudo fonts in the X-session is especially useful when you run X applications for the first time.

Creating pseudo fonts in an X-session is the same as in the Pseudo fonts dialog box. You can use the requested font name as the pseudo font alias. To enable creating pseudo fonts in the X-session, check on the Create pseudo on X client request check box. For batch X clients, it is preferable to disable the option to avoid interactive requests.

Unfortunately, pseudo fonts created on X client's requests become accessible only after restarting the X-session. In the current X-session, XServer uses the default font instead of requested one.

Enabling to Use

You can define whether to use pseudo fonts in the X-session or not.

To disable pseudo fonts, check off the Use pseudo fonts check box. Pseudo Fonts Directory will be removed from Font Path. XServer will only use X fonts. You will not be able to create pseudo fonts in the X-session.

To enable pseudo fonts, check on the Use pseudo fonts check box. The Pseudo fonts priority dialog box will appear.

You should define priority of Pseudo Fonts Directory among other font sources in Font Path. To insert Pseudo Fonts Directory into Font Path, select a position and use the Before selection or After selection buttons. XServer will use pseudo fonts as well as X fonts.

The Advanced Tab

X-session title

In this entry field, you can specify your title for an X-session (and its icon) instead of its default title.
Note: A full title is the X-session title followed by its virtual DisplayNumber.

Initial TCP port number

In this entry field, you can change the default (6000) initial port number for your X-session that XServer will use.

Max size of XSELECTION

This option is used to change the default (1MB) size for X-Selection that may be copied to/from the MS Windows' Clipboard (in Bytes).

Total multi-monitors width
Total multi-monitors height

With these two values, you can set the forced multi-monitors mode if XServer cannot detect the multi-monitors mode automatically.
WWW is the sum width and the HHH is the sum height of your "monitors".
In the Full Screen mode, XServer can only use the MAIN monitor.

Quick X-session termination

This option is used to prevent from displaying the confirmation message on closing X-sessions.

Check of XDesk manager

This option is used to provide the correct focus processing by the XDesk virtual desktop manager.

Enable MS Windows Context Menu

This option is used to enable the standard MS Windows Context Menu (when right-clicks on the window's title bar provide the standard drop-down menu).

Enable Backing Store

This option lets you enable XServer to process the Backing Store mode. See also Forced Backing Store on the Screen Tab.

If this check box is checked, the Backing Store mode will be used with all X clients. This allows X Window System displays to be saved off-screen so that X clients do not have to refresh a window display after it has been obscured by another window. Saving a copy of the information obscured when windows overlap each other reduces network traffic. Certain X-applications will request the Backing Store mode on windows that are complicated to draw. The option will cause XServer to use Backing Store on all windows that the X-application requests it.

If this check box is clear, the Backing Store mode will be turned off so XServer will not save copies of windows information, even if the X-application does request it.

Icon on system TaskBar

This option enables your system to keep the X-session icon (as well as icons of applications started from the XServer's Run menu) in the system taskbar (for the Multiple modes).

Not reset XServer at last X client closing

This option is used to prevent XServer from resetting after the last X client closes its session (for not removing those resources that have been created by X clients run).

Terminate XServer at last X client closing

This option is used to automatically terminate XServer after the last X client closes its session.

Silent Bell

When enabled, this check box will block all sounds (internal sounds and the X-protocol XBell requests).

Auto Clipboard Copy&Paste

This check box controls the mode of connection between the MS Windows Clipboard and the current X Selection. When enabled, then changing of the MS Windows Clipboard contents will force the same change in the current X Selection. Also, changing of the contents of the current X Selection (from the active application window) will automatically cause copying it into the MS Windows Clipboard (so you are ready to paste).

Default

This button sets up the default values for check boxes and edit fields in the box.

The Access Control Box

This box contains the following items that allow you to restrict access to your XServer from remote hosts. You can give access only to the hosts you authorized in the Authorize File and/or you specified in the Valid Hosts File.

Host Access Check

If this check box is checked, then XServer will check host access by using a file you specify in the Valid Hosts File field.

If this check box is disabled, then XServer will not check host access, so every host on your network will have access to your XServer (and the Authorization Check state does not matter).

Valid Hosts File

Use this field to specify a file you created to give access to hosts (and X clients) you wish to connect to your XServer.

This file will be used only if the Host Access Check check box is checked.

The file consists of text lines each of the following format:

IP_address comment
or
name comment

IP addresses are specified in the dotted IP address notation. Names must be specified as official host names or aliases in your hosts file.

Note that the host definition syntax allows you to use your hosts file as the Valid Hosts File.

Authorization Check

If this check box is checked, then XServer will make standard authorization check by using a file you specify in the Authorize File field.

If this check box is disabled, then XServer will not make standard authorization check.

Authorize File

Use this field to specify a file you created to give access to hosts you wish to connect to your XServer (for either XDM and non-XDM clients).

This file will be used only if the Authorization Check check box is checked.

Note: to use the Authorize File, you should copy the standard authorization binary file, ~HOME/.Xauthority, created with the 'xauth' utility on your host.

Auto-reject non-authorized X clients

If this check box is checked, then XServer will suppress the Authorization Audit message. This setting is useful if you want to reject any unauthorized X clients automatically (with no confirmation dialog).

Default

This button sets up the default values for check boxes and edit fields in the Access Control box.

Some Hints about Authorization and Host Access Policy

XServer checks permissions of hosts (and X clients) to establish connection by the following rules:

1. XServer will (firstly) make standard authorization check (if the Authorization Check check box is checked) and will (secondly) check host access (if the Host Access Check check box is checked).
   
   So if the Host Access Check check box is disabled, then every host on your network will have access to your XServer.
   
   
2. If the Authorization Check check box is enabled, and a host is found in the Authorize File, then XServer will give access to the host.
   
   
3. If the Host Access Check check box is enabled, and a host is found in the ValidAccessFile, then XServer will give access to the host.
   
   
4. If the Host Access Check check box is enabled, but the ValidAccessFile field is empty or the file you specified in the field cannot be normally read or the file is empty, and the Authorization Check check box is disabled, then access to your XServer is disabled for all hosts.
   
   
5. To authorize hosts that are absent in the ValidHostsFile, you can enable the Authorization Check check box and specify the Authorize File.

The Troubleshooting Tab

Options that you can specify within this tab are mainly for debug purposes.

Level for slow network

This option enables XServer to avoid the focus-problem when your network (or X client's machine) is slow, and XServer processes the "ButtonRelease" mouse event before it receives the "AllowEvents"/"GrabKeyboard" requests from the corresponding X client.

A slider position defines a priority level of kbd/mse events when redrawing an image that is associated with the mouse pointer position or key. For slow network or X client's machine, it may be preferrable to reduce traffic due to reducing mouse pointer positions transmitted to X clent and so reducing image redrawing.

Display Number for XDMCP

This option enables you to provide a "virtual" value of DisplayNumber for XServer. This value is sent to a remote XDMCP daemon instead of the real value.

Your IP address for XDMCP daemons

This option enables you to specify an IP address that XServer will use to communicate with the XDMCP daemon.
This is applicable when the XServer's PC has more than one IP address. In this case, XServer will use the IP address specified.

MS OpenGL32 pixel format

An integer value in this entry field specifies an appropriate pixel format used by MS Windows OpenGL32 (not in the MESA mode; see GLX Extension on the Screen Tab).

If you enter 0 or leave the field empty, then MS Windows OpenGL32 will use MSDN function ChoosePixelFormat. The ChoosePixelFormat function attempts to match an appropriate pixel format supported by a device context to a given pixel format specification.

If you enter a positive integer, then MS Windows OpenGL32 will use the value to match an appropriate pixel format to a given pixel format specification.

If you enter a negative integer, then MS Windows OpenGL32 will use MSDN function DescribePixelFormat to find an appropriate pixel format. The DescribePixelFormat function obtains information about the pixel format.

Timeout to Font Server

This slider changes the default timeout value used for access to remote font servers.

Disable XServer's options

This entry field disables items from the XServer's Control menu:
Restore, Move, Size, Minimize, Maximize, Close,
Edit, Options, Refresh, LocalRef, Restart, Macros, Run, Messages,
About, Help, LocalWin, Readme.

To disable some of the menu items, enter them in the field comma separated.

IP address to access to XServer

This option enables you to bind an IP address to the XServer's listening socket.
E.g., the 127.0.0.1 value allows access to XServer from local X clients only.

Block font path changing

If disabled, this check box prevents from changing the XServer Font Path by external requests (so remote X clients are not allowed to change Font Resources). The default is OFF.

Refresh screen on changing color cells

This option is used to set the immediate refresh of screen after any color cell of the active colormap is changed.
Be ready that this setting significantly slows down the XServer's performance.

Operate with Linux SuSE 9.0

This option enables XServer to be operational with Linux SuSE 9.0.

This option is relevant to the TrueColor visual mode with the Enable RENDER Extension check box cleared. In this case, XServer will "emulate the 8-bit pixmaps creation" allowing X applications (running under Linux SuSE 9.0) to use 8-bit pixmaps. To enable RENDER Extension is the most correct way.

Display remote WMs in background

This option is used to allow a remote window manager to display in background if it provides this (e.g., olwm does not provide, but dtwm does). Such a background window is suppressed by default because it covers all non-X windows.
This setting is for the XServer's Multiple+RemoteWM mode.

Display any X over all MS windows

This option allows XServer to display any X windows on top of MS windows. This setting is for the XServer's Multiple+RemoteWM mode. In this case, it is convenient to use local mwm.

Connect to 1st answered to broadcast

This option provides the "old-style" way of using the XDMCP broadcast mode.

Not use _MOTIF_WM_HINTS property

This option enables XServer to prevent from processing the "_MOTIF_WM_HINTS" windows property (that may be requested by remote X clients).

• Use _MOTIF_WM_HINTS_move

  This option enables XServer to prevent from processing the "_MOTIF_WM_HINTS_move" windows property (that may be requested by remote X clients).

Not check of WM_SIZE_HINTSinc

This option enables XServer to prevent from processing the "WM_SIZE_HINTS" windows property (that may be requested by remote X clients).

Sound when XServer uses Clipboard

This check box enables system bell sound when XServer will perform Edit operations (i.e., from the Edit menu) with Clipboard.

Not start remote Window Managers

If this check box is selected, XServer will disable starting a remote window manager in answer to its request since there is another window manager already running (for Single and Full Screen modes). In the Multiple modes, only local window managers are allowed to run.

Check of X client's Backing Store

This option is only used in the Multiple and Multiple+RemoteWM modes.

If this check box is enabled, XServer will use the Backing Store mode, when the X-application requests it. But XServer will not use Backing Store while re-displaying an X-application's window in some cases.

If this check box is clear, XServer will use the Backing Store mode, when the X-application requests it.

To try this option may be useful when an X client uses the Backing Store mode and the windows are not properly redrawn.

See also Enable Backing Store on the Advanced Tab.

Default

This button sets up the default values for check boxes and edit fields in the tab.

The Trace Tab

Options that you can specify within this tab are for debug purposes.

Keyboard trace level

A value (one from None, Minimal, Advanced, Full) in this field denotes a tracing level for collecting keyboard trace information for your X-session (e.g., Events of pressing/releasing of keys) to the log file.
None desables keyboard tracing.

XDMCP/ACCESS debug trace into 'c:\xservert.dat' file

If checked, this check box enables writing out any special debugging information into the c:\xservert.dat trace file.
Be careful when using this option because of significant decreasing the XServer's performance and a large size of the trace file.

The Network trace Box

When the Network trace check box is selected, it enables network tracing between XServer and remote X clients.

Network trace level

A value in this field that you can choose from the list box denotes a tracing level for collecting network trace information for your X-session to the log file.

Trace file name

In this entry field, you can specify a name for a log file to store network trace data.

Number of lines for trace buffer

In this entry field, you can type in a length for the allocated memory (in number of lines) to flush it to the trace file.
The value of 0 means a "very large" buffer (as much as your system allows).
Caution: when a system crash happens, the data in the allocated memory is lost.