Penguin
Recent Changes
Annotated edit history of Xnest(1) version 2, including all changes. View license author blame.
Rev Author # Line
2 EricMonson 1 !XNEST(1) !XNEST(1)
1 EricMonson 2
3 NAME
4 Xnest - a nested X server
5
6 SYNOPSIS
2 EricMonson 7 Xnest [[-options]
1 EricMonson 8
9 DESCRIPTION
10 Xnest is a client and a server. Xnest is a client of the real server
11 which manages windows and graphics requests on its behalf. Xnest is a
12 server to its own clients. Xnest manages windows and graphics requests
13 on their behalf. To these clients Xnest appears to be a conventional
14 server.
15
16 OPTIONS
17 Xnest supports all standard options of the sample server implementa-
18 tion. For more details, please see the manual page on your system for
19 Xserver. The following additional arguments are supported as well.
20
21 -display string
22 This option specifies the display name of the real server that
23 Xnest should try to connect with. If it is not provided on the
24 command line Xnest will read the DISPLAY environment variable in
25 order to find out the same information.
26
27 -sync
28 This option tells Xnest to synchronize its window and graphics
29 operations with the real server. This is a useful option for
30 debugging, but it will slow down the performance considerably. It
31 should not be used unless absolutely necessary.
32
33 -full
34 This option tells Xnest to utilize full regeneration of real server
35 objects and reopen a new connection to the real server each time
36 the nested server regenerates. The sample server implementation
37 regenerates all objects in the server when the last client of this
38 server terminates. When this happens, Xnest by default maintains
39 the same top level window and the same real server connection in
40 each new generation. If the user selects full regeneration, even
41 the top level window and the connection to the real server will be
42 regenerated for each server generation.
43
44 -class string
45 This option specifies the default visual class of the nested
46 server. It is similar to the -cc option from the set of standard
47 options except that it will accept a string rather than a number
48 for the visual class specification. The string must be one of the
2 EricMonson 49 following six values: !StaticGray, !GrayScale, !StaticColor, Pseudo-
50 Color, !TrueColor, or !DirectColor. If both, -class and -cc options
1 EricMonson 51 are specified, the last instance of either option assumes prece-
52 dence. The class of the default visual of the nested server need
53 not be the same as the class of the default visual of the real
54 server; although, it has to be supported by the real server. See
55 xdpyinfo for a list of supported visual classes on the real server
56 before starting Xnest. If the user chooses a static class, all the
57 colors in the default colormap will be preallocated. If the user
58 chooses a dynamic class, colors in the default colormap will be
59 available to individual clients for allocation.
60
61 -depth int
62 This option specifies the default visual depth of the nested
63 server. The depth of the default visual of the nested server need
64 not be the same as the depth of the default visual of the real
65 server; although, it has to be supported by the real server. See
66 xdpyinfo for a list of supported visual depths on the real server
67 before starting Xnest.
68
69 -sss
70 This option tells Xnest to use the software screen saver. By
71 default Xnest will use the screen saver that corresponds to the
72 hardware screen saver in the real server. Of course, even this
73 screen saver is software generated since Xnest does not control any
74 actual hardware. However, it is treated as a hardware screen saver
75 within the sample server code.
76
77 -geometry W+H+X+Y
78 This option specifies geometry parameters for the top level Xnest
79 windows. These windows corresponds to the root windows of the
80 nested server. The width and height specified with this option
81 will be the maximum width and height of each top level Xnest win-
82 dow. Xnest will allow the user to make any top level window
83 smaller, but it will not actually change the size of the nested
84 server root window. As of yet, there is no mechanism within the
85 sample server implementation to change the size of the root window
86 after screen initialization. In order to do so, one would probably
87 need to extend the X protocol. Therefore, it is not likely that
88 this will be available any time soon. If this option is not speci-
89 fied Xnest will choose width and height to be 3/4 of the dimensions
90 of the root window of the real server.
91
92 -bw int
93 This option specifies the border width of the top level Xnest win-
94 dow. The integer parameter must be a positive number. The default
95 border width is 1.
96
97 -name string
98 This option specifies the name of the top level Xnest window. The
99 default value is the program name.
100
101 -scrns int
102 This option specifies the number of screens to create in the nested
103 server. For each screen, Xnest will create a separate top level
104 window. Each screen is referenced by the number after the dot in
105 the client display name specification. For example, xterm -display
106 :1.1 will open an xterm client in the nested server with the dis-
107 play number :1 on the second screen. The number of screens is lim-
108 ited by the hard coded constant in the server sample code which is
109 usually 3.
110
111 -install
112 This option tells Xnest to do its own colormap 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 whose
116 colormap should be installed in the real server in the WM_COL-
117 ORMAP_WINDOWS property of the top level Xnest window. If this col-
118 ormap is of the same visual type as the root window of the nested
119 server, Xnest will associate this colormap with the top level Xnest
120 window as well. Since this does not have to be the case, window
121 managers should look primarily at the WM_COLORMAP_WINDOWS property
122 rather than the colormap associated with the top level Xnest win-
123 dow. Unfortunately, window managers are not very good at doing
124 that yet so this option might come in handy.
125
126 -parent window_id
127 This option tells Xnest to use the window_id as the root window
128 instead of creating a window. This option is used by the xrx xnest-
129 plugin.
130
131 USAGE
132 Starting up Xnest is as simple as starting up xclock from a terminal
133 emulator. If a user wishes to run Xnest on the same workstation as the
134 real server, it is important that the nested server is given its own
135 listening socket address. Therefore, if there is a server already run-
136 ning on the user's workstation, Xnest will have to be started up with a
137 new display number. Since there is usually no more than one server
138 running on a workstation, specifying Xnest :1 on the command line will
139 be sufficient for most users. For each server running on the worksta-
140 tion the display number needs to be incremented by one. Thus, if you
141 wish to start another Xnest, you will need to type Xnest :2 on the com-
142 mand line.
143
144 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 in the first nested server and xterm -display
147 :2 will start an xterm in the second nested server from the example
148 above. Additional clients can be started from these xterms in each
149 nested server.
150
151 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. As of now, Xnest assumes
158 that the real server supports the shape extension. There is no way to
159 turn off this assumption dynamically. Xnest can be compiled without
160 the shape extension built in, and in that case the real server need not
161 support it. The dynamic shape extension selection support should be
162 considered in further development of Xnest.
163 Since Xnest need not use the same default visual as the the real
164 server, the top level window of the Xnest client always has its own
165 colormap. This implies that other windows' colors will not be dis-
166 played properly while the keyboard or pointer focus is in the Xnest
167 window, unless the real server has support for more than one installed
168 colormap at any time. The colormap associated with the top window of
169 the Xnest client need not be the appropriate colormap that the nested
170 server wants installed in the real server. In the case that a nested
171 client attempts to install a colormap of a different visual from the
172 default visual of the nested server, Xnest will put the top window of
173 this nested client and all other top windows of the nested clients that
174 use the same colormap into the WM_COLORMAP_WINDOWS property of the top
175 level Xnest window on the real server. Thus, it is important that the
176 real window manager that manages the Xnest top level window looks at
177 the WM_COLORMAP_WINDOWS property rather than the colormap associated
178 with the top level Xnest window. Since most window managers appear to
179 not implement this convention properly as of yet, Xnest can optionally
180 do direct installation of colormaps into the real server bypassing the
181 real window manager. If the user chooses this option, it is usually
182 necessary to temporarily disable the real window manager since it will
183 interfere with the Xnest scheme of colormap installation.
184
185 Keyboard and pointer control procedures of the nested server change the
186 keyboard and pointer control parameters of the real server. Therefore,
187 after Xnest is started up, it will change the keyboard and pointer con-
188 trols of the real server to its own internal defaults. Perhaps there
189 should be a command line option to tell Xnest to inherit the keyboard
190 and pointer control parameters from the real server rather than impos-
191 ing its own. This is a future consideration.
192
193 XNEST AS A SERVER
194 Xnest as a server looks exactly like a real server to its own clients.
195 For the clients there is no way of telling if they are running on a
196 real or a nested server.
197
198 As already mentioned, Xnest is a very user friendly server when it
199 comes to customization. Xnest will pick up a number of command line
200 arguments that can configure its default visual class and depth, number
201 of screens, etc. In the future, Xnest should read a customization
202 input file to provide even greater freedom and simplicity in selecting
203 the desired layout. Unfortunately, there is no support for backing
204 store and save under as of yet, but this should also be considered in
205 the future development of Xnest.
206
207 The only apparent intricacy from the users' perspective about using
208 Xnest as a server is the selection of fonts. Xnest manages fonts by
209 loading them locally and then passing the font name to the real server
210 and asking it to load that font remotely. This approach avoids the
211 overload of sending the glyph bits across the network for every text
212 operation, although it is really a bug. The proper implementation of
213 fonts should be moved into the os layer. The consequence of this
214 approach is that the user will have to worry about two different font
215 paths - a local one for the nested server and a remote one for the real
216 server - since Xnest does not propagate its font path to the real
217 server. The reason for this is because real and nested servers need
218 not run on the same file system which makes the two font paths mutually
219 incompatible. Thus, if there is a font in the local font path of the
220 nested server, there is no guarantee that this font exists in the
221 remote font path of the real server. Xlsfonts client, if run on the
222 nested server will list fonts in the local font path and if run on the
223 real server will list fonts in the remote font path. Before a font can
224 be successfully opened by the nested server it has to exist in local
225 and remote font paths. It is the users' responsibility to make sure
226 that this is the case.
227 BUGS
228 Won't run well on servers supporting different visual depths. Still
229 crashes randomly. Probably has some memory leaks.
230
231 AUTHOR
232 Davor Matic, MIT X Consortium
233
2 EricMonson 234 X Version 11 Release 6.6 !XNEST(1)
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.