1Xnest(1) General Commands Manual Xnest(1)
2
6 Xnest - a nested X server
7
9 Xnest [ options ]
10
12 Xnest is both an X client and an X server. Xnest is a client of the
13 real server which manages windows and graphics requests on its behalf.
14 Xnest is a server to its own clients. Xnest manages windows and graph‐
15 ics requests on their behalf. To these clients, Xnest appears to be a
16 conventional server.
17
19 Xnest supports all standard options of the sample server implementa‐
20 tion. For more details, please see Xserver(1). The following addi‐
21 tional arguments are supported as well.
22 -display string
24 This option specifies the display name of the real server that
25 Xnest should try to connect to. If it is not provided on the
26 command line, Xnest will read the DISPLAY environment variable
27 in order to find out this information.
28 -sync This option tells Xnest to synchronize its window and graphics
30 operations with the real server. This is a useful option for
31 debugging, but it will slow down Xnest's performance consider‐
32 ably. It should not be used unless absolutely necessary.
33 -full This option tells Xnest to utilize full regeneration of real
35 server objects and reopen a new connection to the real server
36 each time the nested server regenerates. The sample server
37 implementation regenerates all objects in the server when the
38 last client of this server terminates. When this happens, Xnest
39 by default maintains the same top-level window and the same real
40 server connection in each new generation. If the user selects
41 full regeneration, even the top-level window and the connection
42 to the real server will be regenerated for each server genera‐
43 tion.
44 -class string
46 This option specifies the default visual class of the nested
47 server. It is similar to the -cc option from the set of stan‐
48 dard options except that it will accept a string rather than a
49 number for the visual class specification. The string must be
50 one of the following six values: StaticGray, GrayScale, Static‐
51 Color, PseudoColor, TrueColor, or DirectColor. If both the
52 -class and -cc options are specified, the last instance of
53 either option takes precedence. The class of the default visual
54 of the nested server need not be the same as the class of the
55 default visual of the real server, but it must be supported by
56 the real server. Use xdpyinfo(1) to obtain a list of supported
57 visual classes on the real server before starting Xnest. If the
58 user chooses a static class, all the colors in the default color
59 map will be preallocated. If the user chooses a dynamic class,
60 colors in the default color map will be available to individual
61 clients for allocation.
62 -depth int
64 This option specifies the default visual depth of the nested
65 server. The depth of the default visual of the nested server
66 need not be the same as the depth of the default visual of the
67 real server, but it must be supported by the real server. Use
68 xdpyinfo(1) to obtain a list of supported visual depths on the
69 real server before starting Xnest.
70 -sss This option tells Xnest to use the software screen saver. By
72 default, Xnest will use the screen saver that corresponds to the
73 hardware screen saver in the real server. Of course, even this
74 screen saver is software-generated since Xnest does not control
75 any actual hardware. However, it is treated as a hardware
76 screen saver within the sample server code.
77 -geometry WxH+X+Y
79 This option specifies the geometry parameters for the top-level
80 Xnest window. See “GEOMETRY SPECIFICATIONS” in X(7) for a dis‐
81 cusson of this option's syntax. This window corresponds to the
82 root window of the nested server. The width W and height H
83 specified with this option will be the maximum width and height
84 of each top-level Xnest window. Xnest will allow the user to
85 make any top-level window smaller, but it will not actually
86 change the size of the nested server root window. Xnest does
87 not yet support the RANDR extension for resizing, rotation, and
88 reflection of the root window. If this option is not specified,
89 Xnest will choose W and H to be 3/4ths the dimensions of the
90 root window of the real server.
91 -bw int
93 This option specifies the border width of the top-level Xnest
94 window. The integer parameter int must be positive. The
95 default border width is 1.
96 -name string
98 This option specifies the name of the top-level Xnest window as
99 string. The default value is the program name.
100 -scrns int
102 This option specifies the number of screens to create in the
103 nested server. For each screen, Xnest will create a separate
104 top-level window. Each screen is referenced by the number after
105 the dot in the client display name specification. For example,
106 xterm -display :1.1 will open an xterm(1) client in the nested
107 server with the display number :1 on the second screen. The
108 number of screens is limited by the hard-coded constant in the
109 server sample code, which is usually 3.
110 -install
112 This option tells Xnest to do its own color map installation by
113 bypassing the real window manager. For it to work properly, the
114 user will probably have to temporarily quit the real window man‐
115 ager. By default, Xnest will keep the nested client window
116 whose color map should be installed in the real server in the
117 WM_COLORMAP_WINDOWS property of the top-level Xnest window. If
118 this color map is of the same visual type as the root window of
119 the nested server, Xnest will associate this color map with the
120 top-level Xnest window as well. Since this does not have to be
121 the case, window managers should look primarily at the WM_COL‐
122 ORMAP_WINDOWS property rather than the color map associated with
123 the top-level Xnest window. Unfortunately, window managers are
124 not very good at doing that yet so this option might come in
125 handy.
126 -parent window_id
128 This option tells Xnest to use window_id as the root window
129 instead of creating a window.
130
132 Starting up Xnest is just as simple as starting up xclock(1) from a
133 terminal emulator. If a user wishes to run Xnest on the same worksta‐
134 tion as the real server, it is important that the nested server is
135 given its own listening socket address. Therefore, if there is a
136 server already running on the user's workstation, Xnest will have to be
137 started up with a new display number. Since there is usually no more
138 than one server running on a workstation, specifying ‘Xnest :1’ on the
139 command line will be sufficient for most users. For each server run‐
140 ning on the workstation, the display number needs to be incremented by
141 one. Thus, if you wish to start another Xnest, you will need to type
142 ‘Xnest :2’ on the command line.
143 To run clients in the nested server, each client needs to be given the
145 same display number as the nested server. For example, ‘xterm -display
146 :1’ will start up an xterm process in the first nested server and
147 ‘xterm -display :2’ will start an xterm in the second nested server
148 from the example above. Additional clients can be started from these
149 xterms in each nested server.
150 Xnest as a client
152 Xnest behaves and looks to the real server and other real clients as
153 another real client. It is a rather demanding client, however, since
154 almost any window or graphics request from a nested client will result
155 in a window or graphics request from Xnest to the real server. There‐
156 fore, it is desirable that Xnest and the real server are on a local
157 network, or even better, on the same machine. Xnest assumes that the
158 real server supports the SHAPE extension. There is no way to turn off
159 this assumption dynamically. Xnest can be compiled without the SHAPE
160 extension built in, in which case the real server need not support it.
161 Dynamic SHAPE extension selection support may be considered in further
162 development of Xnest.
163 Since Xnest need not use the same default visual as the the real
165 server, the top-level window of the Xnest client always has its own
166 color map. This implies that other windows' colors will not be dis‐
167 played properly while the keyboard or pointer focus is in the Xnest
168 window, unless the real server has support for more than one installed
169 color map at any time. The color map associated with the top window of
170 the Xnest client need not be the appropriate color map that the nested
171 server wants installed in the real server. In the case that a nested
172 client attempts to install a color map of a different visual from the
173 default visual of the nested server, Xnest will put the top window of
174 this nested client and all other top windows of the nested clients that
175 use the same color map into the WM_COLORMAP_WINDOWS property of the
176 top-level Xnest window on the real server. Thus, it is important that
177 the real window manager that manages the Xnest top-level window looks
178 at the WM_COLORMAP_WINDOWS property rather than the color map associ‐
179 ated with the top-level Xnest window. Since most window managers don't
180 yet appear to implement this convention properly, Xnest can optionally
181 do direct installation of color maps into the real server bypassing the
182 real window manager. If the user chooses this option, it is usually
183 necessary to temporarily disable the real window manager since it will
184 interfere with the Xnest scheme of color map installation.
185 Keyboard and pointer control procedures of the nested server change the
187 keyboard and pointer control parameters of the real server. Therefore,
188 after Xnest is started up, it will change the keyboard and pointer con‐
189 trols of the real server to its own internal defaults.
190 Xnest as a server
192 Xnest as a server looks exactly like a real server to its own clients.
193 For the clients, there is no way of telling if they are running on a
194 real or a nested server.
195 As already mentioned, Xnest is a very user-friendly server when it
197 comes to customization. Xnest will pick up a number of command-line
198 arguments that can configure its default visual class and depth, number
199 of screens, etc.
200 The only apparent intricacy from the users' perspective about using
202 Xnest as a server is the selection of fonts. Xnest manages fonts by
203 loading them locally and then passing the font name to the real server
204 and asking it to load that font remotely. This approach avoids the
205 overload of sending the glyph bits across the network for every text
206 operation, although it is really a bug. The consequence of this
207 approach is that the user will have to worry about two different font
208 paths — a local one for the nested server and a remote one for the real
209 server — since Xnest does not propagate its font path to the real
210 server. The reason for this is because real and nested servers need
211 not run on the same file system which makes the two font paths mutually
212 incompatible. Thus, if there is a font in the local font path of the
213 nested server, there is no guarantee that this font exists in the
214 remote font path of the real server. The xlsfonts(1) client, if run on
215 the nested server, will list fonts in the local font path and, if run
216 on the real server, will list fonts in the remote font path. Before a
217 font can be successfully opened by the nested server, it has to exist
218 in local and remote font paths. It is the users' responsibility to
219 make sure that this is the case.
220
222 Make dynamic the requirement for the SHAPE extension in the real
223 server, rather than having to recompile Xnest to turn this requirement
224 on and off.
225 Perhaps there should be a command-line option to tell Xnest to inherit
227 the keyboard and pointer control parameters from the real server rather
228 than imposing its own.
229 Xnest should read a customization input file to provide even greater
231 freedom and simplicity in selecting the desired layout.
232 There is no support for backing store and save unders, but this should
234 also be considered.
235 The proper implementation of fonts should be moved into the os layer.
237
239 Doesn't run well on servers supporting different visual depths.
240 Still crashes randomly.
242 Probably has some memory leaks.
244
246 Davor Matic, MIT X Consortium
247
249 Xserver(1), xdpyinfo(1), X(7)
250X Version 11 xorg-server 1.20.10 Xnest(1)