Commit | Line | Data |
---|---|---|
a09e091a JB |
1 | .\" |
2 | .\" Copyright 2001-2004 Red Hat Inc., Durham, North Carolina. | |
3 | .\" All Rights Reserved. | |
4 | .\" | |
5 | .\" Permission is hereby granted, free of charge, to any person obtaining | |
6 | .\" a copy of this software and associated documentation files (the | |
7 | .\" "Software"), to deal in the Software without restriction, including | |
8 | .\" without limitation on the rights to use, copy, modify, merge, | |
9 | .\" publish, distribute, sublicense, and/or sell copies of the Software, | |
10 | .\" and to permit persons to whom the Software is furnished to do so, | |
11 | .\" subject to the following conditions: | |
12 | .\" | |
13 | .\" The above copyright notice and this permission notice (including the | |
14 | .\" next paragraph) shall be included in all copies or substantial | |
15 | .\" portions of the Software. | |
16 | .\" | |
17 | .\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, | |
18 | .\" EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF | |
19 | .\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND | |
20 | .\" NON-INFRINGEMENT. IN NO EVENT SHALL RED HAT AND/OR THEIR SUPPLIERS | |
21 | .\" BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN | |
22 | .\" ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN | |
23 | .\" CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE | |
24 | .\" SOFTWARE. | |
25 | .TH Xdmx 1 __vendorversion__ | |
26 | .SH NAME | |
27 | Xdmx - Distributed Multi-head X server | |
28 | .SH SYNOPSIS | |
29 | .B Xdmx | |
30 | [:display] [option ...] | |
31 | .SH DESCRIPTION | |
32 | .I Xdmx | |
33 | is a proxy X server that uses one or more other X servers as its display | |
34 | devices. It provides multi-head X functionality for displays that might | |
35 | be located on different machines. | |
36 | .I Xdmx | |
37 | functions as a front-end X server that acts as a proxy to a set of | |
38 | back-end X servers. All of the visible rendering is passed to the | |
39 | back-end X servers. Clients connect to the | |
40 | .I Xdmx | |
41 | front-end, and everything appears as it would in a regular multi-head | |
42 | configuration. If Xinerama is enabled (e.g., with | |
43 | .B +xinerama | |
44 | on the command line), the clients see a single large screen. | |
45 | .PP | |
46 | .I Xdmx | |
47 | communicates to the back-end X servers using the standard X11 protocol, | |
48 | and standard and/or commonly available X server extensions. | |
49 | .SH OPTIONS | |
50 | In addition to the normal X server options described in the | |
51 | .I Xserver(__appmansuffix__) | |
52 | manual page, | |
53 | .I Xdmx | |
54 | accepts the following command line switches: | |
55 | .TP 8 | |
56 | .BI "\-display " display-name | |
57 | This specifies the name(s) of the back-end X server display(s) to connect | |
58 | to. This option may be specified multiple times to connect to more than | |
59 | one back-end display. The first is used as screen 0, the second as screen 1, | |
60 | etc. If this option is omitted, the | |
61 | .B $DISPLAY | |
62 | environment variable is used as the single back-end X server display. | |
63 | .sp | |
64 | .TP 8 | |
65 | .BI "\-xinput " input-source | |
66 | This specifies the source to use for XInput extension devices. The | |
67 | choices are the same as for | |
68 | .BR "\-input " , | |
69 | described below, except that core devices on backend servers cannot be | |
70 | treated as XInput extension devices. (Although extension devices on | |
71 | backend and console servers are supported as extension devices under | |
72 | .IR Xdmx ). | |
73 | .sp | |
74 | .TP 8 | |
75 | .BI "\-input " input-source | |
76 | This specifies the source to use for the core input devices. The choices are: | |
77 | .RS | |
78 | .TP 4 | |
79 | .B dummy | |
80 | A set of dummy core input drivers are used. These never generate any | |
81 | input events. | |
82 | .sp | |
83 | .TP 4 | |
84 | .B local | |
85 | The raw keyboard and pointer from the local computer are used. A | |
86 | comma-separated list of driver names can be appended. For example, to | |
87 | select the example Linux keyboard and PS/2 mouse driver use: | |
88 | .BR "-input local,kbd,ps2" . | |
89 | The following drivers have been implemented for Linux: kbd, ms (a | |
90 | two-button Microsoft mouse driver), ps2 (a PS/2 mouse driver), usb-mou | |
91 | (a USB mouse driver), usb-kbd (a USB keyboard driver), and usb-oth (a | |
92 | USB non-keyboard, non-mouse driver). Additional drivers may be | |
93 | implemented in the future. Appropriate defaults will be used if no | |
94 | comma-separated list is provided. | |
95 | .sp | |
96 | .TP 4 | |
97 | .I display-name | |
98 | If the display-name is a back-end server, then core input events are | |
99 | taken from the server specified. Otherwise, a console window will be | |
100 | opened on the specified display. | |
101 | .sp | |
102 | If the | |
103 | .I display-name | |
104 | is followed by ",xi" then XInput extension devices on the display will | |
105 | be used as | |
106 | .I Xdmx | |
107 | XInput extension devices. If the | |
108 | .I display-name | |
109 | is followed by ",noxi" then XInput extension devices on the display will | |
110 | .B not | |
111 | be used as | |
112 | .I Xdmx | |
113 | XInput extension devices. Currently, the default is ",xi". | |
114 | .sp | |
115 | If the | |
116 | .I display-name | |
117 | is followed by ",console" and the | |
118 | .I display-name | |
119 | refers to a display that is used as a backend display, then a console | |
120 | window will be opened on that display | |
121 | .B and | |
122 | that display will be treated as a backend display. Otherwise (or if | |
123 | ",noconsole" is used), the display will be treated purely as a backend | |
124 | or a console display, as described above. | |
125 | .sp | |
126 | If the | |
127 | .I display-name | |
128 | is followed by ",windows", then outlines of the windows on the backend | |
129 | will be displayed inside the console window. Otherwise (or if | |
130 | ",nowindows" is used), the console window will not display the outlines | |
131 | of backend windows. (This option only applies to console input.) | |
132 | .sp | |
133 | If the | |
134 | .I display-name | |
135 | is followed by ",xkb", then the next 1 to 3 comma-separated parameters | |
136 | will specify the keycodes, symbols, and geometry of the keyboard for | |
137 | this input device. For example, ",xkb,xfree86,pc104" will specify that | |
138 | the "xfree86" keycodes and the "pc104" symbols should be used to | |
139 | initialize the keyboard. For an SGI keyboard, ",xkb,sgi/indy(pc102)" | |
140 | might be useful. A list of keycodes, symbols, and geometries can be | |
141 | found in | |
142 | .IR __xkbdir__ . | |
143 | Use of keycodes, symbols and geometries for XKB configuration is | |
144 | deprecated in favor of the rules, layout, model, variant and options | |
145 | settings available via the -param command line switch. | |
146 | If this option is not specified, the input device will be queried, | |
147 | perhaps using the XKEYBOARD extension. | |
148 | .RE | |
149 | .sp | |
150 | .RS | |
151 | If this option isn't specified, the default input source is the first | |
152 | back-end server (the one used for screen 0). The console window shows | |
153 | the layout of the back-end display(s) and pointer movements and key | |
154 | presses within the console window will be used as core input devices. | |
155 | .sp | |
156 | Several special function keys are active, depending on the input | |
157 | source: | |
158 | .sp | |
159 | .RS | |
160 | .B Ctrl-Alt-q | |
161 | will terminate the | |
162 | .I Xdmx | |
163 | server in all modes. | |
164 | .sp | |
165 | .B Ctrl-Alt-g | |
166 | will toggle a | |
167 | server grab in console mode (a special cursor, currently a spider, is | |
168 | used to indicate an active server grab). | |
169 | .sp | |
170 | .B Ctrl-Alt-f | |
171 | will toggle fine-grain motion in console mode (a special cursor, | |
172 | currently a cross hair, is used to indicate this mode). If this mode is | |
173 | combined with a server grab, then the cursor will have 4 lines instead | |
174 | of only 2. | |
175 | .sp | |
176 | .BR Ctrl-Alt-F1 " through " Ctrl-Alt-F12 | |
177 | will switch to another VC in local (raw) mode. | |
178 | .RE | |
179 | .RE | |
180 | .sp | |
181 | .TP 8 | |
182 | .BI "-nomulticursor" | |
183 | This option turns off support for displaying multiple cursors on | |
184 | overlapped back-end displays. This option is available for testing and | |
185 | benchmarking purposes. | |
186 | .sp | |
187 | .TP 8 | |
188 | .BI "-fontpath" | |
189 | This option sets the | |
190 | .I Xdmx | |
191 | server's default font path. This option can be specified multiple times | |
192 | to accommodate multiple font paths. See the | |
193 | .B "FONT PATHS" | |
194 | section below for very important information regarding setting the | |
195 | default font path. | |
196 | .sp | |
197 | .TP 8 | |
198 | .BI "-configfile " filename | |
199 | Specify the configuration file that should be read. Note that if the | |
200 | .B \-display | |
201 | command-line option is used, then the configuration file will be | |
202 | ignored. | |
203 | .sp | |
204 | .TP 8 | |
205 | .BI "-config " name | |
206 | Specify a configuration to use. The | |
207 | .I name | |
208 | will be the name following the | |
209 | .B virtual | |
210 | keyword in the configuration file. | |
211 | .sp | |
212 | .TP 8 | |
213 | .BI "-stat " "interval screens" | |
214 | This option enables the display of performance statistics. The interval | |
215 | is in seconds. The screens is a count of the number of back-end screens | |
216 | for which data is printed each interval. Specifying 0 for screens will | |
217 | display data for all screens. | |
218 | .sp | |
219 | For each screen, the following information is printed: the screen | |
220 | number, an absolute count of the number of XSync() calls made | |
221 | (SyncCount), the rate of these calls during the previous interval | |
222 | (Sync/s), the average round-trip time (in microseconds) of the last 10 | |
223 | XSync() calls (avSync), the maximum round-trip time (in microseconds) of | |
224 | the last 10 XSync calls (mxSync), the average number of XSync() requests | |
225 | that were pending but not yet processed for each of the last 10 | |
226 | processed XSync() calls, the maximum number of XSync() requests that | |
227 | were pending but not yet processed for each of the last 10 processed | |
228 | XSync() calls, and a histogram showing the distribution of the times of | |
229 | all of the XSync() calls that were made during the previous interval. | |
230 | .sp | |
231 | (The length of the moving average and the number and value of histogram | |
232 | bins are configurable at compile time in the | |
233 | .B dmxstat.h | |
234 | header file.) | |
235 | .sp | |
236 | .TP 8 | |
237 | .BI "-syncbatch " interval | |
238 | This option sets the | |
239 | .I interval | |
240 | in milliseconds for XSync() batching. An | |
241 | .I interval | |
242 | less than or equal to 0 will disable XSync() batching. The default | |
243 | .I interval | |
244 | is 100 ms. | |
245 | .sp | |
246 | .TP 8 | |
247 | .BI "-nooffscreenopt" | |
248 | This option disables the offscreen optimization. Since the lazy window | |
249 | creation optimization requires the offscreen optimization to be enabled, | |
250 | this option will also disable the lazy window creation optimization. | |
251 | .sp | |
252 | .TP 8 | |
253 | .BI "-nowindowopt" | |
254 | This option disables the lazy window creation optimization. | |
255 | .sp | |
256 | .TP 8 | |
257 | .BI "-nosubdivprims" | |
258 | This option disables the primitive subdivision optimization. | |
259 | .sp | |
260 | .TP 8 | |
261 | .BI "-noxkb" | |
262 | Disable use of the XKB extension for communication with the back end | |
263 | displays. (Combine with | |
264 | .B "-kb" | |
265 | to disable all use of XKB.) | |
266 | .sp | |
267 | .TP 8 | |
268 | .BI "-depth " int | |
269 | This option sets the root window's default depth. When choosing a | |
270 | default visual from those available on the back-end X server, the first | |
271 | visual with that matches the depth specified is used. | |
272 | .sp | |
273 | This option can be combined with the | |
274 | .BI "-cc" | |
275 | option, which specifies the default color visual class, to force the use | |
276 | of a specific depth and color class for the root window. | |
277 | .sp | |
278 | .TP 8 | |
279 | .BI "-norender" | |
280 | This option disables the RENDER extension. | |
281 | .sp | |
282 | .TP 8 | |
283 | .BI "-noglxproxy" | |
284 | This option disables GLX proxy -- the build-in GLX extension | |
285 | implementation that is DMX aware. | |
286 | .sp | |
287 | .TP 8 | |
288 | .BI "-noglxswapgroup" | |
289 | This option disables the swap group and swap barrier extensions in GLX | |
290 | proxy. | |
291 | .sp | |
292 | .TP 8 | |
293 | .BI "-glxsyncswap" | |
294 | This option enables synchronization after a swap buffers call by waiting | |
295 | until all X protocol has been processed. When a client issues a | |
296 | glXSwapBuffers request, Xdmx relays that request to each back-end X | |
297 | server, and those requests are buffered along with all other protocol | |
298 | requests. However, in systems that have large network buffers, this | |
299 | buffering can lead to the set of back-end X servers handling the swap | |
300 | buffers request asynchronously. With this option, an XSync() request is | |
301 | issued to each back-end X server after sending the swap buffers request. | |
302 | The XSync() requests will flush all buffered protocol (including the | |
303 | swap buffers requests) and wait until the back-end X servers have | |
304 | processed those requests before continuing. This option does not wait | |
305 | until all GL commands have been processed so there might be previously | |
306 | issued commands that are still being processed in the GL pipe when the | |
307 | XSync() request returns. See the | |
308 | .BI "-glxfinishswap" | |
309 | option below if Xdmx should wait until the GL commands have been | |
310 | processed. | |
311 | .sp | |
312 | .TP 8 | |
313 | .BI "-glxfinishswap" | |
314 | This option enables synchronization after a swap buffers call by waiting | |
315 | until all GL commands have been completed. It is similar to the | |
316 | .BI "-glxsyncswap" | |
317 | option above; however, instead of issuing an XSync(), it issues a | |
318 | glFinish() request to each back-end X server after sending the swap | |
319 | buffers requests. The glFinish() request will flush all buffered | |
320 | protocol requests, process both X and GL requests, and wait until all | |
321 | previously called GL commands are complete before returning. | |
322 | .sp | |
323 | .TP 8 | |
324 | .BI "-ignorebadfontpaths" | |
325 | This option ignores font paths that are not available on all back-end | |
326 | servers by removing the bad font path(s) from the default font path | |
327 | list. If no valid font paths are left after removing the bad paths, an | |
328 | error to that effect is printed in the log. | |
329 | .sp | |
330 | .TP 8 | |
331 | .BI "-addremovescreens" | |
332 | This option enables the dynamic addition and removal of screens, which | |
333 | is disabled by default. Note that GLXProxy and Render do not yet | |
334 | support dynamic addition and removal of screens, and must be disabled | |
335 | via the | |
336 | .BI "-noglxproxy" | |
337 | and | |
338 | .BI "-norender" | |
339 | command line options described above. | |
340 | .sp | |
341 | .TP 8 | |
342 | .BI "-param" | |
343 | This option specifies parameters on the command line. Currently, only | |
344 | parameters dealing with XKEYBOARD configuration are supported. These | |
345 | parameters apply only to the core keyboard. Parameter values are | |
346 | installation-dependent. Please see | |
347 | .I __xkbdir__ | |
348 | or a similar directory for complete information. | |
349 | .RS | |
350 | .TP 8 | |
351 | .B XkbRules | |
352 | Defaults to "__XKB_DFLT_RULES__". Other values may include "sgi" and "sun". | |
353 | .sp | |
354 | .TP 8 | |
355 | .B XkbModel | |
356 | Defaults to "__XKB_DFLT_MODEL__". When used with "base" rules, other values | |
357 | may include "pc102", "pc104", "microsoft", and many others. When | |
358 | used with "sun" rules, other values may include "type4" and "type5". | |
359 | .sp | |
360 | .TP 8 | |
361 | .B XkbLayout | |
362 | Defaults to "__XKB_DFLT_LAYOUT__". Other country codes and "dvorak" are usually | |
363 | available. | |
364 | .sp | |
365 | .TP 8 | |
366 | .B XkbVariant | |
367 | Defaults to "__XKB_DFLT_VARIANT__". | |
368 | .sp | |
369 | .TP 8 | |
370 | .B XkbOptions | |
371 | Defaults to "__XKB_DFLT_OPTIONS__". | |
372 | .RE | |
373 | .SH "CONFIGURATION FILE GRAMMAR" | |
374 | The following words and tokens are reserved: | |
375 | .RS | |
376 | .B virtual | |
377 | .B display | |
378 | .B wall | |
379 | .B option | |
380 | .B param | |
381 | .B { | |
382 | .B } | |
383 | .B ; | |
384 | .B # | |
385 | .RE | |
386 | .PP | |
387 | Comments start with a | |
388 | .B # | |
389 | mark and extend to the end of the line. They may appear anywhere. If a | |
390 | configuration file is read into | |
391 | .BR xdmxconfig , | |
392 | the comments in that file will be preserved, but will not be editable. | |
393 | .PP | |
394 | The grammar is as follows: | |
395 | .RS | |
396 | virtual-list ::= [ virtual-list ] | virtual | |
397 | ||
398 | virtual ::= | |
399 | .B virtual | |
400 | [ name ] [ dim ] | |
401 | .B { | |
402 | dw-list | |
403 | .B } | |
404 | ||
405 | dw-list ::= [ dw-list ] | dw | |
406 | ||
407 | dw ::= display | wall | option | |
408 | ||
409 | display ::= | |
410 | .B display | |
411 | name [ geometry ] [ / geometry ] [ origin ] | |
412 | .B ; | |
413 | ||
414 | wall ::= | |
415 | .B wall | |
416 | [ dim ] [ dim ] name-list | |
417 | .B ; | |
418 | ||
419 | option ::= | |
420 | .B option | |
421 | name-list | |
422 | .B ; | |
423 | ||
424 | param ::= | |
425 | .B param | |
426 | name-list | |
427 | .B ; | |
428 | ||
429 | param ::= | |
430 | .B param { | |
431 | param-list | |
432 | .B } | |
433 | ||
434 | param-list ::= [ param-list ] | name-list | |
435 | .B ; | |
436 | ||
437 | name-list ::= [ name-list ] | name | |
438 | ||
439 | name ::= string | double-quoted-string | |
440 | ||
441 | dim ::= integer | |
442 | .B x | |
443 | integer | |
444 | ||
445 | geometry ::= [ integer | |
446 | .B x | |
447 | integer ] [ signed-integer signed-integer ] | |
448 | ||
449 | origin ::= | |
450 | .B @ | |
451 | integer | |
452 | .B x | |
453 | integer | |
454 | .RE | |
455 | .PP | |
456 | The name following | |
457 | .B virtual | |
458 | is used as an identifier for the configuration, and may be passed to | |
459 | .B Xdmx | |
460 | using the | |
461 | .B \-config | |
462 | command line option. The name of a display should be standard X display | |
463 | name, although no checking is performed (e.g., "machine:0"). | |
464 | .PP | |
465 | For names, double quotes are optional unless the name is reserved or | |
466 | contains spaces. | |
467 | .PP | |
468 | The first dimension following | |
469 | .B wall | |
470 | is the dimension for tiling (e.g., 2x4 or 4x4). The second dimension | |
471 | following | |
472 | .B wall | |
473 | is the dimension of each display in the wall (e.g., 1280x1024). | |
474 | .PP | |
475 | The first geometry following | |
476 | .B display | |
477 | is the geometry of the screen window on the backend server. The second | |
478 | geometry, which is always preceeded by a slash, is the geometry of the | |
479 | root window. By default, the root window has the same geometry as the | |
480 | screen window. | |
481 | .PP | |
482 | The | |
483 | .B option | |
484 | line can be used to specify any command-line options (e.g., | |
485 | .BR \-input ). | |
486 | (It cannot be used to specify the name of the front-end display.) The | |
487 | option line is processed once at server startup, just line command line | |
488 | options. This behavior may be unexpected. | |
489 | .SH "CONFIGURATION FILE EXAMPLES" | |
490 | Two displays being used for a desktop may be specified in any of the | |
491 | following formats: | |
492 | .RS | |
493 | .nf | |
494 | virtual example0 { | |
495 | display d0:0 1280x1024 @0x0; | |
496 | display d1:0 1280x1024 @1280x0; | |
497 | } | |
498 | .sp | |
499 | virtual example1 { | |
500 | display d0:0 1280x1024; | |
501 | display d1:0 @1280x0; | |
502 | } | |
503 | .sp | |
504 | virtual example2 { | |
505 | display "d0:0"; | |
506 | display "d1:0" @1280x0; | |
507 | } | |
508 | .sp | |
509 | virtual example3 { wall 2x1 d0:0 d1:0; } | |
510 | .fi | |
511 | .RE | |
512 | A 4x4 wall of 16 total displays could be specified as follows (if no | |
513 | tiling dimension is specified, an approximate square is used): | |
514 | .RS | |
515 | .nf | |
516 | virtual example4 { | |
517 | wall d0:0 d1:0 d2:0 d3:0 | |
518 | d4:0 d5:0 d6:0 d7:0 | |
519 | d8:0 d9:0 da:0 db:0 | |
520 | dc:0 dd:0 de:0 df:0; | |
521 | } | |
522 | .fi | |
523 | .RE | |
524 | .SH "FONT PATHS" | |
525 | The font path used by the | |
526 | .I Xdmx | |
527 | front-end server will be propagated to each back-end server,which | |
528 | requires that each back-end server have access to the exact same font | |
529 | paths as the front-end server. This can be most easily handled by | |
530 | either using a font server (e.g., xfs) or by remotely mounting the font | |
531 | paths on each back-end server, and then setting the | |
532 | .I Xdmx | |
533 | server's default font path with the | |
534 | -I "-fontpath" | |
535 | command line option described above. | |
536 | .PP | |
537 | For example, if you specify a font path with the following command line: | |
538 | .RS | |
539 | Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath /usr/fonts/Type1/ +xinerama | |
540 | .RE | |
541 | Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths | |
542 | on the | |
543 | .I Xdmx | |
544 | server and all back-end server, which is d0 in this example. | |
545 | .PP | |
546 | Font servers can also be specified with the | |
547 | .I "-fontpath" | |
548 | option. For example, let's assume that a properly configured font | |
549 | server is running on host d0. Then, the following command line | |
550 | .RS | |
551 | Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xinerama | |
552 | .RE | |
553 | will initialize the front-end | |
554 | .I Xdmx | |
555 | server and each of the back-end servers to use the font server on d0. | |
556 | .PP | |
557 | Some fonts might not be supported by either the front-end or the | |
558 | back-end servers. For example, let's assume the front-end | |
559 | .I Xdmx | |
560 | server includes support Type1 fonts, but one of the back-end servers | |
561 | does not. Let's also assume that the default font path for | |
562 | .I Xdmx | |
563 | includes Type1 fonts in its font path. Then, when | |
564 | .I Xdmx | |
565 | initializes the default font path to load the default font, the font | |
566 | path that includes Type1 fonts (along with the other default font paths | |
567 | that are used by the | |
568 | .I Xdmx | |
569 | server) is sent to the back-end server that cannot handle Type1 fonts. | |
570 | That back-end server then rejects the font path and sends an error back | |
571 | to the | |
572 | .I Xdmx | |
573 | server. | |
574 | .I Xdmx | |
575 | then prints an error message and exits because it failed to set the | |
576 | default font path and was unable load the default font. | |
577 | .PP | |
578 | To fix this error, the offending font path must be removed from the | |
579 | default font path by using a different | |
580 | .I "-fontpath" | |
581 | command line option. | |
582 | .PP | |
583 | The | |
584 | .I "-fontpath" | |
585 | option can also be added to the configuration file as described above. | |
586 | .SH "COMMAND-LINE EXAMPLES" | |
587 | The back-end machines are d0 and d1, core input is from the pointer and | |
588 | keyboard attached to d0, clients will refer to :1 when opening windows: | |
589 | .RS | |
590 | Xdmx :1 -display d0:0 -display d1:0 +xinerama | |
591 | .RE | |
592 | .PP | |
593 | As above, except with core input from d1: | |
594 | .RS | |
595 | Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama | |
596 | .RE | |
597 | .PP | |
598 | As above, except with core input from a console window on the local | |
599 | display: | |
600 | .RS | |
601 | Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama | |
602 | .RE | |
603 | .PP | |
604 | As above, except with core input from the local keyboard and mouse: | |
605 | .RS | |
606 | Xdmx :1 -display d0:0 -display d1:0 -input local,kbd,ps2 +xinerama | |
607 | .RE | |
608 | Note that local input can be used under Linux while another X session is | |
609 | running on :0 (assuming the user can access the Linux console tty and | |
610 | mouse devices): a new (blank) VC will be used for keyboard input on the | |
611 | local machine and the Ctrl-Alt-F* sequence will be available to change | |
612 | to another VC (possibly back to another X session running on the local | |
613 | machine). Using Ctrl-Alt-Backspace on the blank VC will terminate the | |
614 | Xdmx session and return to the original VC. | |
615 | .PP | |
616 | This example uses the configuration file shown in the previous section: | |
617 | .RS | |
618 | Xdmx :1 -input :0 +xinerama -configfile filename -config example2 | |
619 | .RE | |
620 | With this configuration file line: | |
621 | .RS | |
622 | option -input :0 +xinerama; | |
623 | .RE | |
624 | the command line can be shortened to: | |
625 | .RS | |
626 | Xdmx :1 -configfile filename -config example2 | |
627 | .RE | |
628 | .SH "USING THE USB DEVICE DRIVERS" | |
629 | .P | |
630 | The USB device drivers use the devices called | |
631 | .IR /dev/input/event0 ", " /dev/input/event1 ", etc." | |
632 | under Linux. These devices are driven using the | |
633 | .I evdev | |
634 | Linux kernel module, which is part of the hid suite. Please note that | |
635 | if you load the | |
636 | .I mousedev | |
637 | or | |
638 | .I kbddev | |
639 | Linux kernel modules, then USB devices will appear as core Linux input | |
640 | devices and you will not be able to select between using the device only | |
641 | as an | |
642 | .I Xdmx | |
643 | core device or an | |
644 | .I Xdmx | |
645 | XInput extension device. Further, you may be unable to unload the | |
646 | .I mousedev | |
647 | Linux kernel module if | |
648 | .I XFree86 | |
649 | is configured to use | |
650 | .I /dev/input/mice | |
651 | as an input device (this is quite helpful for laptop users and is set up | |
652 | by default under some Linux distributions, but should be changed if USB | |
653 | devices are to be used with | |
654 | .IR Xdmx ). | |
655 | .PP | |
656 | The USB device drivers search through the Linux devices for the first | |
657 | mouse, keyboard, or non-mouse-non-keyboard Linux device and use that | |
658 | device. | |
659 | .SH "KEYBOARD INITIALIZATION" | |
660 | .PP | |
661 | If | |
662 | .I Xdmx | |
663 | was invoked with | |
664 | .I \-xkb | |
665 | or was | |
666 | .B not | |
667 | compiled to use the XKEYBOARD extension, then a keyboard on a backend or | |
668 | console will be initialized using the map that the host X server | |
669 | provides. | |
670 | .PP | |
671 | If the XKEYBOARD extension is used for both | |
672 | .I Xdmx | |
673 | and the host X server for the keyboard (i.e., the backend or console X | |
674 | server), then the type of the keyboard will | |
675 | be obtained from the host X server and the keyboard under | |
676 | .I Xdmx | |
677 | will be initialized with that information. Otherwise, the default type | |
678 | of keyboard will be initialized. In both cases, the map from the host X | |
679 | server will | |
680 | .B not | |
681 | be used. This means that different initial behavior may be noted with | |
682 | and without XKEYBOARD. Consistent and expected results will be obtained | |
683 | by running XKEYBOARD on all servers and by avoiding the use of | |
684 | .I xmodmap | |
685 | on the backend or console X servers prior to starting | |
686 | .IR Xdmx . | |
687 | .PP | |
688 | If | |
689 | .I \-xkbmap | |
690 | is specified on the | |
691 | .I Xdmx | |
692 | command line, then that map will currently be used for all keyboards. | |
693 | .SH "MULTIPLE CORE KEYBOARDS" | |
694 | X was not designed to support multiple core keyboards. However, | |
695 | .I Xdmx | |
696 | provides some support for multiple core keyboards. Best results will be | |
697 | obtained if all of the keyboards are of the same type and are using the | |
698 | same keyboard map. Because the X server passes raw key code information | |
699 | to the X client, key symbols for keyboards with different key maps would | |
700 | be different if the key code for each keyboard was sent without | |
701 | translation to the client. Therefore, | |
702 | .I Xdmx | |
703 | will attempt to translate the key code from a core keyboard to the key | |
704 | code for the key with the same key symbol of the | |
705 | .B first | |
706 | core keyboard that was loaded. If the key symbol appears in both maps, | |
707 | the results will be expected. Otherwise, the second core keyboard will | |
708 | return a NoSymbol key symbol for some keys that would have been | |
709 | translated if it was the first core keyboard. | |
710 | .ig | |
711 | .SH ENVIRONMENT | |
712 | .. | |
713 | .ig | |
714 | .SH FILES | |
715 | .. | |
716 | .SH "SEE ALSO" | |
717 | .BR DMX "(__libmansuffix__), " X "(__miscmansuffix__), " | |
718 | .BR Xserver "(__appmansuffix__), " xdmxconfig "(__appmansuffix__), " | |
719 | .BR vdltodmx "(__appmansuffix__), " xfs "(__appmansuffix__), " | |
720 | .BR xkbcomp "(__appmansuffix__), " xkeyboard-config "(__miscmansuffix__)" | |
721 | .SH AUTHORS | |
722 | Kevin E. Martin | |
723 | .I <kem@redhat.com>, | |
724 | David H. Dawes | |
725 | .I <dawes@xfree86.org>, | |
726 | and | |
727 | Rickard E. (Rik) Faith | |
728 | .IR <faith@redhat.com> . | |
729 | .PP | |
730 | Portions of | |
731 | .I Xdmx | |
732 | are based on code from The XFree86 Project | |
733 | .RI ( http://www.xfree86.org ) | |
734 | and X.Org | |
735 | .RI ( http://www.x.org ). |