Xnest supports all standard options of the sample server implementation. For more details, please see the manual page on your system for Xserver. 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 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.
-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 the 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, -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 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.
-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; although, it has to be supported by the real server. See xdpyinfo for 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 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.
-bw int
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.
-name string
This option specifies the name of the top level Xnest window. 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 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 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.
-parent window_id
This option tells Xnest to use the window_id as the root window instead of creating a window. This option is used by the xrx xnestplugin.