Xnest - a nested X server
Xnest is both an X client and an X 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.
Xnest supports all standard options of the sample server implementation.
  For more details, please see Xserver(1). The following additional
  arguments are supported as well.
  - -display string
- This option specifies the display name of the real server that
      Xnest should try to connect to. If it is not provided on the
      command line, Xnest will read the DISPLAY environment
      variable in order to find out this information.
- -sync
- 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 Xnest's performance considerably. It should
      not be used unless absolutely necessary.
- -full
- 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.
- -class string
- 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 the
      -class and -cc options are specified, the last instance of
      either option takes 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, but it must be supported by the real server. Use
      xdpyinfo(1) to obtain 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 color map will be preallocated. If
      the user chooses a dynamic class, colors in the default color map will be
      available to individual clients for allocation.
- -depth int
- 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, but it must be
      supported by the real server. Use xdpyinfo(1) to obtain a list of
      supported visual depths on the real server before starting
    Xnest.
- -sss
- 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.
- -geometry
    WxH+X+Y
- This option specifies the geometry parameters for the top-level
      Xnest window. See “GEOMETRY SPECIFICATIONS” in
      X(7) for a discusson of this option's syntax. This window
      corresponds to the root window of the nested server. The width W
      and height H 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. Xnest does not
      yet support the RANDR extension for resizing, rotation, and reflection of
      the root window. If this option is not specified, Xnest will choose
      W and H to be 3/4ths the dimensions of the root window of
      the real server.
- -bw int
- This option specifies the border width of the top-level Xnest
      window. The integer parameter int must be positive. The default
      border width is 1.
- -name string
- This option specifies the name of the top-level Xnest window as
      string. The default value is the program name.
- -scrns int
- 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(1) 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.
- -install
- This option tells Xnest to do its own color map 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 color map should be
      installed in the real server in the WM_COLORMAP_WINDOWS property of
      the top-level Xnest window. If this color map is of the same visual
      type as the root window of the nested server, Xnest will associate
      this color map 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 color map 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.
- -parent window_id
- This option tells Xnest to use window_id as the root window
      instead of creating a window.
Starting up Xnest is just as simple as starting up xclock(1) 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 process 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.
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. 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, in which case the real server need not support it. Dynamic SHAPE extension
  selection support may be considered in further development of Xnest.
Since Xnest need not use the same default visual as the the
    real server, the top-level window of the Xnest client always has its
    own color map. 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 color map at
    any time. The color map associated with the top window of the Xnest
    client need not be the appropriate color map that the nested server wants
    installed in the real server. In the case that a nested client attempts to
    install a color map 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 color map
    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 color map associated
    with the top-level Xnest window. Since most window managers don't yet
    appear to implement this convention properly, Xnest can optionally do
    direct installation of color maps 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 color map 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.
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.
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 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. The xlsfonts(1) 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.
Make dynamic the requirement for the SHAPE extension in the real server, rather
  than having to recompile Xnest to turn this requirement on and off.
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.
Xnest should read a customization input file to provide
    even greater freedom and simplicity in selecting the desired layout.
There is no support for backing store and save unders, but this
    should also be considered.
The proper implementation of fonts should be moved into the
    os layer.
Doesn't run well on servers supporting different visual depths.
Still crashes randomly.
Probably has some memory leaks.
Davor Matic, MIT X Consortium
Xserver(1), xdpyinfo(1), X(7)