| 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 ). |