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 "-shadowfb"
183 This option turns on (legacy) support for the shadow frame buffer.
184 .sp
185 .TP 8
186 .BI "-noshadowfb"
187 This option turns off (legacy) support for the shadow frame buffer.
188 Note that this option has been deprecated and will be removed in the
189 next release.
190 .sp
191 .TP 8
192 .BI "-nomulticursor"
193 This option turns off support for displaying multiple cursors on
194 overlapped back-end displays. This option is available for testing and
195 benchmarking purposes.
196 .sp
197 .TP 8
198 .BI "-fontpath"
199 This option sets the
200 .I Xdmx
201 server's default font path. This option can be specified multiple times
202 to accommodate multiple font paths. See the
203 .B "FONT PATHS"
204 section below for very important information regarding setting the
205 default font path.
206 .sp
207 .TP 8
208 .BI "-configfile " filename
209 Specify the configuration file that should be read. Note that if the
210 .B \-display
211 command-line option is used, then the configuration file will be
212 ignored.
213 .sp
214 .TP 8
215 .BI "-config " name
216 Specify a configuration to use. The
217 .I name
218 will be the name following the
219 .B virtual
220 keyword in the configuration file.
221 .sp
222 .TP 8
223 .BI "-stat " "interval screens"
224 This option enables the display of performance statistics. The interval
225 is in seconds. The screens is a count of the number of back-end screens
226 for which data is printed each interval. Specifying 0 for screens will
227 display data for all screens.
228 .sp
229 For each screen, the following information is printed: the screen
230 number, an absolute count of the number of XSync() calls made
231 (SyncCount), the rate of these calls during the previous interval
232 (Sync/s), the average round-trip time (in microseconds) of the last 10
233 XSync() calls (avSync), the maximum round-trip time (in microseconds) of
234 the last 10 XSync calls (mxSync), the average number of XSync() requests
235 that were pending but not yet processed for each of the last 10
236 processed XSync() calls, the maximum number of XSync() requests that
237 were pending but not yet processed for each of the last 10 processed
238 XSync() calls, and a histogram showing the distribution of the times of
239 all of the XSync() calls that were made during the previous interval.
240 .sp
241 (The length of the moving average and the number and value of histogram
242 bins are configurable at compile time in the
243 .B dmxstat.h
244 header file.)
245 .sp
246 .TP 8
247 .BI "-syncbatch " interval
248 This option sets the
249 .I interval
250 in milliseconds for XSync() batching. An
251 .I interval
252 less than or equal to 0 will disable XSync() batching. The default
253 .I interval
254 is 100 ms.
255 .sp
256 .TP 8
257 .BI "-nooffscreenopt"
258 This option disables the offscreen optimization. Since the lazy window
259 creation optimization requires the offscreen optimization to be enabled,
260 this option will also disable the lazy window creation optimization.
261 .sp
262 .TP 8
263 .BI "-nowindowopt"
264 This option disables the lazy window creation optimization.
265 .sp
266 .TP 8
267 .BI "-nosubdivprims"
268 This option disables the primitive subdivision optimization.
269 .sp
270 .TP 8
271 .BI "-noxkb"
272 Disable use of the XKB extension for communication with the back end
273 displays. (Combine with
274 .B "-kb"
275 to disable all use of XKB.)
276 .sp
277 .TP 8
278 .BI "-depth " int
279 This option sets the root window's default depth. When choosing a
280 default visual from those available on the back-end X server, the first
281 visual with that matches the depth specified is used.
282 .sp
283 This option can be combined with the
284 .BI "-cc"
285 option, which specifies the default color visual class, to force the use
286 of a specific depth and color class for the root window.
287 .sp
288 .TP 8
289 .BI "-norender"
290 This option disables the RENDER extension.
291 .sp
292 .TP 8
293 .BI "-noglxproxy"
294 This option disables GLX proxy -- the build-in GLX extension
295 implementation that is DMX aware.
296 .sp
297 .TP 8
298 .BI "-noglxswapgroup"
299 This option disables the swap group and swap barrier extensions in GLX
300 proxy.
301 .sp
302 .TP 8
303 .BI "-glxsyncswap"
304 This option enables synchronization after a swap buffers call by waiting
305 until all X protocol has been processed. When a client issues a
306 glXSwapBuffers request, Xdmx relays that request to each back-end X
307 server, and those requests are buffered along with all other protocol
308 requests. However, in systems that have large network buffers, this
309 buffering can lead to the set of back-end X servers handling the swap
310 buffers request asynchronously. With this option, an XSync() request is
311 issued to each back-end X server after sending the swap buffers request.
312 The XSync() requests will flush all buffered protocol (including the
313 swap buffers requests) and wait until the back-end X servers have
314 processed those requests before continuing. This option does not wait
315 until all GL commands have been processed so there might be previously
316 issued commands that are still being processed in the GL pipe when the
317 XSync() request returns. See the
318 .BI "-glxfinishswap"
319 option below if Xdmx should wait until the GL commands have been
320 processed.
321 .sp
322 .TP 8
323 .BI "-glxfinishswap"
324 This option enables synchronization after a swap buffers call by waiting
325 until all GL commands have been completed. It is similar to the
326 .BI "-glxsyncswap"
327 option above; however, instead of issuing an XSync(), it issues a
328 glFinish() request to each back-end X server after sending the swap
329 buffers requests. The glFinish() request will flush all buffered
330 protocol requests, process both X and GL requests, and wait until all
331 previously called GL commands are complete before returning.
332 .sp
333 .TP 8
334 .BI "-ignorebadfontpaths"
335 This option ignores font paths that are not available on all back-end
336 servers by removing the bad font path(s) from the default font path
337 list. If no valid font paths are left after removing the bad paths, an
338 error to that effect is printed in the log.
339 .sp
340 .TP 8
341 .BI "-addremovescreens"
342 This option enables the dynamic addition and removal of screens, which
343 is disabled by default. Note that GLXProxy and Render do not yet
344 support dynamic addition and removal of screens, and must be disabled
345 via the
346 .BI "-noglxproxy"
347 and
348 .BI "-norender"
349 command line options described above.
350 .sp
351 .TP 8
352 .BI "-param"
353 This option specifies parameters on the command line. Currently, only
354 parameters dealing with XKEYBOARD configuration are supported. These
355 parameters apply only to the core keyboard. Parameter values are
356 installation-dependent. Please see
357 .I __xkbdir__
358 or a similar directory for complete information.
359 .RS
360 .TP 8
361 .B XkbRules
362 Defaults to "__XKB_DFLT_RULES__". Other values may include "sgi" and "sun".
363 .sp
364 .TP 8
365 .B XkbModel
366 Defaults to "__XKB_DFLT_MODEL__". When used with "base" rules, other values
367 may include "pc102", "pc104", "microsoft", and many others. When
368 used with "sun" rules, other values may include "type4" and "type5".
369 .sp
370 .TP 8
371 .B XkbLayout
372 Defaults to "__XKB_DFLT_LAYOUT__". Other country codes and "dvorak" are usually
373 available.
374 .sp
375 .TP 8
376 .B XkbVariant
377 Defaults to "__XKB_DFLT_VARIANT__".
378 .sp
379 .TP 8
380 .B XkbOptions
381 Defaults to "__XKB_DFLT_OPTIONS__".
382 .RE
383 .SH "CONFIGURATION FILE GRAMMAR"
384 The following words and tokens are reserved:
385 .RS
386 .B virtual
387 .B display
388 .B wall
389 .B option
390 .B param
391 .B {
392 .B }
393 .B ;
394 .B #
395 .RE
396 .PP
397 Comments start with a
398 .B #
399 mark and extend to the end of the line. They may appear anywhere. If a
400 configuration file is read into
401 .BR xdmxconfig ,
402 the comments in that file will be preserved, but will not be editable.
403 .PP
404 The grammar is as follows:
405 .RS
406 virtual-list ::= [ virtual-list ] | virtual
408 virtual ::=
409 .B virtual
410 [ name ] [ dim ]
411 .B {
412 dw-list
413 .B }
415 dw-list ::= [ dw-list ] | dw
417 dw ::= display | wall | option
419 display ::=
420 .B display
421 name [ geometry ] [ / geometry ] [ origin ]
422 .B ;
424 wall ::=
425 .B wall
426 [ dim ] [ dim ] name-list
427 .B ;
429 option ::=
430 .B option
431 name-list
432 .B ;
434 param ::=
435 .B param
436 name-list
437 .B ;
439 param ::=
440 .B param {
441 param-list
442 .B }
444 param-list ::= [ param-list ] | name-list
445 .B ;
447 name-list ::= [ name-list ] | name
449 name ::= string | double-quoted-string
451 dim ::= integer
452 .B x
453 integer
455 geometry ::= [ integer
456 .B x
457 integer ] [ signed-integer signed-integer ]
459 origin ::=
460 .B @
461 integer
462 .B x
463 integer
464 .RE
465 .PP
466 The name following
467 .B virtual
468 is used as an identifier for the configuration, and may be passed to
469 .B Xdmx
470 using the
471 .B \-config
472 command line option. The name of a display should be standard X display
473 name, although no checking is performed (e.g., "machine:0").
474 .PP
475 For names, double quotes are optional unless the name is reserved or
476 contains spaces.
477 .PP
478 The first dimension following
479 .B wall
480 is the dimension for tiling (e.g., 2x4 or 4x4). The second dimension
481 following
482 .B wall
483 is the dimension of each display in the wall (e.g., 1280x1024).
484 .PP
485 The first geometry following
486 .B display
487 is the geometry of the screen window on the backend server. The second
488 geometry, which is always preceeded by a slash, is the geometry of the
489 root window. By default, the root window has the same geometry as the
490 screen window.
491 .PP
492 The
493 .B option
494 line can be used to specify any command-line options (e.g.,
495 .BR \-input ).
496 (It cannot be used to specify the name of the front-end display.) The
497 option line is processed once at server startup, just line command line
498 options. This behavior may be unexpected.
499 .SH "CONFIGURATION FILE EXAMPLES"
500 Two displays being used for a desktop may be specified in any of the
501 following formats:
502 .RS
503 .nf
504 virtual example0 {
505 display d0:0 1280x1024 @0x0;
506 display d1:0 1280x1024 @1280x0;
507 }
508 .sp
509 virtual example1 {
510 display d0:0 1280x1024;
511 display d1:0 @1280x0;
512 }
513 .sp
514 virtual example2 {
515 display "d0:0";
516 display "d1:0" @1280x0;
517 }
518 .sp
519 virtual example3 { wall 2x1 d0:0 d1:0; }
520 .fi
521 .RE
522 A 4x4 wall of 16 total displays could be specified as follows (if no
523 tiling dimension is specified, an approximate square is used):
524 .RS
525 .nf
526 virtual example4 {
527 wall d0:0 d1:0 d2:0 d3:0
528 d4:0 d5:0 d6:0 d7:0
529 d8:0 d9:0 da:0 db:0
530 dc:0 dd:0 de:0 df:0;
531 }
532 .fi
533 .RE
534 .SH "FONT PATHS"
535 The font path used by the
536 .I Xdmx
537 front-end server will be propagated to each back-end server,which
538 requires that each back-end server have access to the exact same font
539 paths as the front-end server. This can be most easily handled by
540 either using a font server (e.g., xfs) or by remotely mounting the font
541 paths on each back-end server, and then setting the
542 .I Xdmx
543 server's default font path with the
544 -I "-fontpath"
545 command line option described above.
546 .PP
547 For example, if you specify a font path with the following command line:
548 .RS
549 Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath /usr/fonts/Type1/ +xinerama
550 .RE
551 Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths
552 on the
553 .I Xdmx
554 server and all back-end server, which is d0 in this example.
555 .PP
556 Font servers can also be specified with the
557 .I "-fontpath"
558 option. For example, let's assume that a properly configured font
559 server is running on host d0. Then, the following command line
560 .RS
561 Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xinerama
562 .RE
563 will initialize the front-end
564 .I Xdmx
565 server and each of the back-end servers to use the font server on d0.
566 .PP
567 Some fonts might not be supported by either the front-end or the
568 back-end servers. For example, let's assume the front-end
569 .I Xdmx
570 server includes support Type1 fonts, but one of the back-end servers
571 does not. Let's also assume that the default font path for
572 .I Xdmx
573 includes Type1 fonts in its font path. Then, when
574 .I Xdmx
575 initializes the default font path to load the default font, the font
576 path that includes Type1 fonts (along with the other default font paths
577 that are used by the
578 .I Xdmx
579 server) is sent to the back-end server that cannot handle Type1 fonts.
580 That back-end server then rejects the font path and sends an error back
581 to the
582 .I Xdmx
583 server.
584 .I Xdmx
585 then prints an error message and exits because it failed to set the
586 default font path and was unable load the default font.
587 .PP
588 To fix this error, the offending font path must be removed from the
589 default font path by using a different
590 .I "-fontpath"
591 command line option.
592 .PP
593 The
594 .I "-fontpath"
595 option can also be added to the configuration file as described above.
596 .SH "COMMAND-LINE EXAMPLES"
597 The back-end machines are d0 and d1, core input is from the pointer and
598 keyboard attached to d0, clients will refer to :1 when opening windows:
599 .RS
600 Xdmx :1 -display d0:0 -display d1:0 +xinerama
601 .RE
602 .PP
603 As above, except with core input from d1:
604 .RS
605 Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
606 .RE
607 .PP
608 As above, except with core input from a console window on the local
609 display:
610 .RS
611 Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama
612 .RE
613 .PP
614 As above, except with core input from the local keyboard and mouse:
615 .RS
616 Xdmx :1 -display d0:0 -display d1:0 -input local,kbd,ps2 +xinerama
617 .RE
618 Note that local input can be used under Linux while another X session is
619 running on :0 (assuming the user can access the Linux console tty and
620 mouse devices): a new (blank) VC will be used for keyboard input on the
621 local machine and the Ctrl-Alt-F* sequence will be available to change
622 to another VC (possibly back to another X session running on the local
623 machine). Using Ctrl-Alt-Backspace on the blank VC will terminate the
624 Xdmx session and return to the original VC.
625 .PP
626 This example uses the configuration file shown in the previous section:
627 .RS
628 Xdmx :1 -input :0 +xinerama -configfile filename -config example2
629 .RE
630 With this configuration file line:
631 .RS
632 option -input :0 +xinerama;
633 .RE
634 the command line can be shortened to:
635 .RS
636 Xdmx :1 -configfile filename -config example2
637 .RE
638 .SH "USING THE USB DEVICE DRIVERS"
639 .P
640 The USB device drivers use the devices called
641 .IR /dev/input/event0 ", " /dev/input/event1 ", etc."
642 under Linux. These devices are driven using the
643 .I evdev
644 Linux kernel module, which is part of the hid suite. Please note that
645 if you load the
646 .I mousedev
647 or
648 .I kbddev
649 Linux kernel modules, then USB devices will appear as core Linux input
650 devices and you will not be able to select between using the device only
651 as an
652 .I Xdmx
653 core device or an
654 .I Xdmx
655 XInput extension device. Further, you may be unable to unload the
656 .I mousedev
657 Linux kernel module if
658 .I XFree86
659 is configured to use
660 .I /dev/input/mice
661 as an input device (this is quite helpful for laptop users and is set up
662 by default under some Linux distributions, but should be changed if USB
663 devices are to be used with
664 .IR Xdmx ).
665 .PP
666 The USB device drivers search through the Linux devices for the first
667 mouse, keyboard, or non-mouse-non-keyboard Linux device and use that
668 device.
669 .SH "KEYBOARD INITIALIZATION"
670 .PP
671 If
672 .I Xdmx
673 was invoked with
674 .I \-xkb
675 or was
676 .B not
677 compiled to use the XKEYBOARD extension, then a keyboard on a backend or
678 console will be initialized using the map that the host X server
679 provides.
680 .PP
681 If the XKEYBOARD extension is used for both
682 .I Xdmx
683 and the host X server for the keyboard (i.e., the backend or console X
684 server), then the type of the keyboard will
685 be obtained from the host X server and the keyboard under
686 .I Xdmx
687 will be initialized with that information. Otherwise, the default type
688 of keyboard will be initialized. In both cases, the map from the host X
689 server will
690 .B not
691 be used. This means that different initial behavior may be noted with
692 and without XKEYBOARD. Consistent and expected results will be obtained
693 by running XKEYBOARD on all servers and by avoiding the use of
694 .I xmodmap
695 on the backend or console X servers prior to starting
696 .IR Xdmx .
697 .PP
698 If
699 .I \-xkbmap
700 is specified on the
701 .I Xdmx
702 command line, then that map will currently be used for all keyboards.
703 .SH "MULTIPLE CORE KEYBOARDS"
704 X was not designed to support multiple core keyboards. However,
705 .I Xdmx
706 provides some support for multiple core keyboards. Best results will be
707 obtained if all of the keyboards are of the same type and are using the
708 same keyboard map. Because the X server passes raw key code information
709 to the X client, key symbols for keyboards with different key maps would
710 be different if the key code for each keyboard was sent without
711 translation to the client. Therefore,
712 .I Xdmx
713 will attempt to translate the key code from a core keyboard to the key
714 code for the key with the same key symbol of the
715 .B first
716 core keyboard that was loaded. If the key symbol appears in both maps,
717 the results will be expected. Otherwise, the second core keyboard will
718 return a NoSymbol key symbol for some keys that would have been
719 translated if it was the first core keyboard.
720 .ig
721 .SH ENVIRONMENT
722 ..
723 .ig
724 .SH FILES
725 ..
726 .SH "SEE ALSO"
727 .BR DMX "(__libmansuffix__), " X "(__miscmansuffix__), "
728 .BR Xserver "(__appmansuffix__), " xdmxconfig "(__appmansuffix__), "
729 .BR vdltodmx "(__appmansuffix__), " xfs "(__appmansuffix__), "
730 .BR xkbcomp "(__appmansuffix__), " xkeyboard-config "(__miscmansuffix__)"
731 .SH AUTHORS
732 Kevin E. Martin
733 .I <kem@redhat.com>,
734 David H. Dawes
735 .I <dawes@xfree86.org>,
736 and
737 Rickard E. (Rik) Faith
738 .IR <faith@redhat.com> .
739 .PP
740 Portions of
741 .I Xdmx
742 are based on code from The XFree86 Project
743 .RI ( http://www.xfree86.org )
744 and X.Org
745 .RI ( http://www.x.org ).