Xnest - a nested X server
Xnest [-options]
Xnest supports all standard options of the sample server
implementation. For more details, see Xdec(1X). The following
additional arguments are supported as well. This
option specifies the display name of the real server that
Xnest should try to connect with. If it is not provided
on the command line Xnest will read the DISPLAY environment
variable in order to find out the same information.
This option tells Xnest to synchronize its window and
graphics operations with the real server. This is a useful
option for debugging, but it will slow down the performance
considerably. It should not be used unless absolutely
necessary. This option tells Xnest to utilize full
regeneration of real server objects and reopen a new connection
to the real server each time the nested server
regenerates. The sample server implementation regenerates
all objects in the server when the last client of this
server terminates. When this happens, Xnest by default
maintains the same top level window and the same real
server connection in each new generation. If the user
selects full regeneration, even the top level window and
the connection to the real server will be regenerated for
each server generation. This option specifies the default
visual class of the nested server. It is similar to the
-cc option from the set of standard options except that it
will accept a string rather than a number for the visual
class specification. The string must be one of the following
six values: StaticGray, GrayScale, StaticColor,
PseudoColor, TrueColor, or DirectColor. If both, -class
and -cc options are specified, the last instance of either
option assumes precedence. The class of the default
visual of the nested server need not be the same as the
class of the default visual of the real server; although,
it has to be supported by the real server. See xdpyinfo(1X) for a list of supported visual classes on the
real server before starting Xnest. If the user chooses a
static class, all the colors in the default colormap will
be preallocated. If the user chooses a dynamic class,
colors in the default colormap will be available to individual
clients for allocation. Specifies the name of a
configuration file to use to configure the loadable X nest
server. The default configuration file is
/usr/var/X11/Xnest.conf This option specifies the default
visual depth of the nested server. The depth of the
default visual of the nested server need not be the same
as the depth of the default visual of the real server;
although, it has to be supported by the real server. See
xdpyinfo(1X) for a list of supported visual depths on the
real server before starting Xnest. This option tells
Xnest to use the software screen saver. By default Xnest
will use the screen saver that corresponds to the hardware
screen saver in the real server. Of course, even this
screen saver is software generated since Xnest does not
control any actual hardware. However, it is treated as a
hardware screen saver within the sample server code. This
option specifies geometry parameters for the top level
Xnest windows. These windows corresponds to the root windows
of the nested server. The width and height specified
with this option will be the maximum width and height of
each top level Xnest window. Xnest will allow the user to
make any top level window smaller, but it will not actually
change the size of the nested server root window. As
of yet, there is no mechanism within the sample server
implementation to change the size of the root window after
screen initialization. In order to do so, one would probably
need to extend the X protocol. Therefore, it is not
likely that this will be available any time soon. If this
option is not specified Xnest will choose width and height
to be 3/4 of the dimensions of the root window of the real
server. This option specifies the border width of the top
level Xnest window. The integer parameter must be a positive
number. The default border width is 1. This option
specifies the name of the top level Xnest window. The
default value is the program name. This option specifies
the number of screens to create in the nested server. For
each screen, Xnest will create a separate top level window.
Each screen is referenced by the number after the
dot in the client display name specification. For example,
xterm -display :1.1 will open an xterm client in the
nested server with the display number :1 on the second
screen. The number of screens is limited by the hard
coded constant in the server sample code which is usually
3. This option tells Xnest to do its own colormap installation
by bypassing the real window manager. For it to
work properly the user will probably have to temporarily
quit the real window manager. By default Xnest will keep
the nested client window whose colormap should be
installed in the real server in the WM_COLORMAP_WINDOWS
property of the top level Xnest window. If this colormap
is of the same visual type as the root window of the
nested server, Xnest will associate this colormap with the
top level Xnest window as well. Since this does not have
to be the case, window managers should look primarily at
the WM_COLORMAP_WINDOWS property rather than the colormap
associated with the top level Xnest window. Unfortunately,
window managers are not very good at doing that
yet so this option might come in handy.
Xnest is a client and a server. Xnest is a client of the
real server which manages windows and graphics requests on
its behalf. Xnest is a server to its own clients. Xnest
manages windows and graphics requests on their behalf. To
these clients Xnest appears to be a conventional server.
The Xnest command supports the run-time loading and execution
of X nest server libraries on Tru64 UNIX platforms.
The command loads appropriate libraries installed on the
workstation and can be configured to use any or all of the
extension libraries available on your workstation.
Starting up Xnest is as simple as starting up xclock from
a terminal emulator. If a user wishes to run Xnest on the
same workstation as the real server, it is important that
the nested server is given its own listening socket
address. Therefore, if there is a server already running
on the user's workstation, Xnest will have to be started
up with a new display number. Since there is usually no
more than one server running on a workstation, specifying
Xnest :1 on the command line will be sufficient for most
users. For each server running on the workstation the
display number needs to be incremented by one. Thus, if
you wish to start another Xnest, you will need to type
Xnest :2 on the command line.
To run clients in the nested server each client needs to
be given the same display number as the nested server.
For example, xterm -display :1 will start up an xterm in
the first nested server and xterm -display :2 will start
an xterm in the second nested server from the example
above. Additional clients can be started from these
xterms in each nested server.
When the Xnest command is started, it uses a set of internal
default lists of components to build an X server. It
also reads a system configuration file
(/usr/var/X11/Xnest.conf or the file specified by the
-config option) to supplement or replace components on the
lists. The command loads all system and core components
and then transfers execution to the core components.
The core components then load the list of extensions provided
and initialize the extensions. Extensions listed in
the configuration file are loaded when a client queries
the extension. The core components also load any font
renderers, transport handlers, and authorization protocol
methods specified in the configurations.
The configuration file syntax is described in the Xdec(1X)
man page.
The Xnest command searches for libraries using the
library_path specified in the configuration file or the
LD_LIBRARY_PATH environment variable. Each component in
the colon separated path is searched. The default search
path is /usr/shlib/X11:/usr/shlib.
The default system installation provides a sample configuration
file /usr/var/X11/Xnest.conf. It contains comments
and shows examples for setting up library lists, library
sub-lists, the library search path, and sample argument
lists.
Xnest behaves and looks to the real server and other real
clients as another real client. It is a rather demanding
client, however, since almost any window or graphics
request from a nested client will result in a window or
graphics request from Xnest to the real server. Therefore,
it is desirable that Xnest and the real server are
on a local network, or even better, on the same machine.
As of now, Xnest assumes that the real server supports the
shape extension. There is no way to turn off this assumption
dynamically. Xnest can be compiled without the shape
extension built in, and in that case the real server need
not support it. The dynamic shape extension selection
support should be considered in further development of
Xnest.
Since Xnest need not use the same default visual as the
real server, the top level window of the Xnest client
always has its own colormap. This implies that other windows'
colors will not be displayed properly while the keyboard
or pointer focus is in the Xnest window, unless the
real server has support for more than one installed
colormap at any time. The colormap associated with the
top window of the Xnest client need not be the appropriate
colormap that the nested server wants installed in the
real server. In the case that a nested client attempts to
install a colormap of a different visual from the default
visual of the nested server, Xnest will put the top window
of this nested client and all other top windows of the
nested clients that use the same colormap into the WM_COLORMAP_WINDOWS
property of the top level Xnest window on
the real server. Thus, it is important that the real window
manager that manages the Xnest top level window looks
at the WM_COLORMAP_WINDOWS property rather than the colormap
associated with the top level Xnest window. Since
most window managers appear to not implement this convention
properly as of yet, Xnest can optionally do direct
installation of colormaps into the real server bypassing
the real window manager. If the user chooses this option,
it is usually necessary to temporarily disable the real
window manager since it will interfere with the Xnest
scheme of colormap installation.
Keyboard and pointer control procedures of the nested
server change the keyboard and pointer control parameters
of the real server. Therefore, after Xnest is started up,
it will change the keyboard and pointer controls of the
real server to its own internal defaults. Perhaps there
should be a command line option to tell Xnest to inherit
the keyboard and pointer control parameters from the real
server rather than imposing its own. This is a future
consideration.
Xnest as a server looks exactly like a real server to its
own clients. For the clients there is no way of telling
if they are running on a real or a nested server.
As already mentioned, Xnest is a very user friendly server
when it comes to customization. Xnest will pick up a number
of command line arguments that can configure its
default visual class and depth, number of screens, etc.
In the future, Xnest should read a customization input
file to provide even greater freedom and simplicity in
selecting the desired layout. Unfortunately, there is no
support for backing store and save under as of yet, but
this should also be considered in the future development
of Xnest.
The only apparent intricacy from the users' perspective
about using Xnest as a server is the selection of fonts.
Xnest manages fonts by loading them locally and then passing
the font name to the real server and asking it to load
that font remotely. This approach avoids the overload of
sending the glyph bits across the network for every text
operation, although it is really a bug. The proper implementation
of fonts should be moved into the os layer. The
consequence of this approach is that the user will have to
worry about two different font paths -- a local one for
the nested server and a remote one for the real server --
since Xnest does not propagate its font path to the real
server. The reason for this is because real and nested
servers need not run on the same file system which makes
the two font paths mutually incompatible. Thus, if there
is a font in the local font path of the nested server,
there is no guarantee that this font exists in the remote
font path of the real server. Xlsfonts client, if run on
the nested server will list fonts in the local font path
and if run on the real server will list fonts in the
remote font path. Before a font can be successfully
opened by the nested server it has to exist in local and
remote font paths. It is the users' responsibility to
make sure that this is the case.
Won't run well on servers supporting different visual
depths. Still crashes randomly. Probably has some memory
leaks.
Davor Matic, MIT X Consortium
Xnest(1X)
[ Back ] |
