|
NAMEXdmx - Distributed Multi-head X serverSYNOPSISXdmx [:display] [option ...]DESCRIPTIONXdmx is a proxy X server that uses one or more other X servers as its display devices. It provides multi-head X functionality for displays that might be located on different machines. Xdmx functions as a front-end X server that acts as a proxy to a set of back-end X servers. All of the visible rendering is passed to the back-end X servers. Clients connect to the Xdmx front-end, and everything appears as it would in a regular multi-head configuration. If Xinerama is enabled (e.g., with +xinerama on the command line), the clients see a single large screen.Xdmx communicates to the back-end X servers using the standard X11 protocol, and standard and/or commonly available X server extensions. OPTIONSIn addition to the normal X server options described in the Xserver(1) manual page, Xdmx accepts the following command line switches:
If this option isn't specified, the default input source
is the first back-end server (the one used for screen 0). The console window
shows the layout of the back-end display(s) and pointer movements and key
presses within the console window will be used as core input devices.
Several special function keys are active, depending on the input source: Ctrl-Alt-q will terminate the Xdmx server
in all modes.
Ctrl-Alt-g will toggle a server grab in console mode (a special cursor, currently a spider, is used to indicate an active server grab). Ctrl-Alt-f will toggle fine-grain motion in console mode (a special cursor, currently a cross hair, is used to indicate this mode). If this mode is combined with a server grab, then the cursor will have 4 lines instead of only 2. Ctrl-Alt-F1 through Ctrl-Alt-F12 will switch to another VC in local (raw) mode.
CONFIGURATION FILE GRAMMARThe following words and tokens are reserved:virtual display wall option
param { } ; #
Comments start with a # mark and extend to the end of the line. They may appear anywhere. If a configuration file is read into xdmxconfig, the comments in that file will be preserved, but will not be editable. The grammar is as follows: virtual-list ::= [ virtual-list ] | virtual
virtual ::= virtual [ name ] [ dim ] { dw-list } dw-list ::= [ dw-list ] | dw dw ::= display | wall | option display ::= display name [ geometry ] [ / geometry ] [ origin ] ; wall ::= wall [ dim ] [ dim ] name-list ; option ::= option name-list ; param ::= param name-list ; param ::= param { param-list } param-list ::= [ param-list ] | name-list ; name-list ::= [ name-list ] | name name ::= string | double-quoted-string dim ::= integer x integer geometry ::= [ integer x integer ] [ signed-integer signed-integer ] origin ::= @ integer x integer The name following virtual is used as an identifier for the configuration, and may be passed to Xdmx using the -config command line option. The name of a display should be standard X display name, although no checking is performed (e.g., "machine:0"). For names, double quotes are optional unless the name is reserved or contains spaces. The first dimension following wall is the dimension for tiling (e.g., 2x4 or 4x4). The second dimension following wall is the dimension of each display in the wall (e.g., 1280x1024). The first geometry following display is the geometry of the screen window on the backend server. The second geometry, which is always preceeded by a slash, is the geometry of the root window. By default, the root window has the same geometry as the screen window. The option line can be used to specify any command-line options (e.g., -input). (It cannot be used to specify the name of the front-end display.) The option line is processed once at server startup, just line command line options. This behavior may be unexpected. CONFIGURATION FILE EXAMPLESTwo displays being used for a desktop may be specified in any of the following formats:virtual example0 { display d0:0 1280x1024 @0x0; display d1:0 1280x1024 @1280x0; } virtual example1 { display d0:0 1280x1024; display d1:0 @1280x0; } virtual example2 { display "d0:0"; display "d1:0" @1280x0; } virtual example3 { wall 2x1 d0:0 d1:0; } virtual example4 { wall d0:0 d1:0 d2:0 d3:0 d4:0 d5:0 d6:0 d7:0 d8:0 d9:0 da:0 db:0 dc:0 dd:0 de:0 df:0; } FONT PATHSThe font path used by the Xdmx front-end server will be propagated to each back-end server,which requires that each back-end server have access to the exact same font paths as the front-end server. This can be most easily handled by either using a font server (e.g., xfs) or by remotely mounting the font paths on each back-end server, and then setting the Xdmx server's default font path with the -I "-fontpath" command line option described above.For example, if you specify a font path with the following command line: Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/
-fontpath /usr/fonts/Type1/ +xinerama
Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths on the
Xdmx server and all back-end server, which is d0 in this example.
Font servers can also be specified with the -fontpath option. For example, let's assume that a properly configured font server is running on host d0. Then, the following command line Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100
+xinerama
will initialize the front-end Xdmx server and each of the back-end
servers to use the font server on d0.
Some fonts might not be supported by either the front-end or the back-end servers. For example, let's assume the front-end Xdmx server includes support Type1 fonts, but one of the back-end servers does not. Let's also assume that the default font path for Xdmx includes Type1 fonts in its font path. Then, when Xdmx initializes the default font path to load the default font, the font path that includes Type1 fonts (along with the other default font paths that are used by the Xdmx server) is sent to the back-end server that cannot handle Type1 fonts. That back-end server then rejects the font path and sends an error back to the Xdmx server. Xdmx then prints an error message and exits because it failed to set the default font path and was unable load the default font. To fix this error, the offending font path must be removed from the default font path by using a different -fontpath command line option. The -fontpath option can also be added to the configuration file as described above. COMMAND-LINE EXAMPLESThe back-end machines are d0 and d1, core input is from the pointer and keyboard attached to d0, clients will refer to :1 when opening windows:Xdmx :1 -display d0:0 -display d1:0 +xinerama
As above, except with core input from d1: Xdmx :1 -display d0:0 -display d1:0 -input d1:0
+xinerama
As above, except with core input from a console window on the local display: Xdmx :1 -display d0:0 -display d1:0 -input :0
+xinerama
As above, except with core input from the local keyboard and mouse: Xdmx :1 -display d0:0 -display d1:0 -input
local,usb-kbd,usb-mou +xinerama
Note that local input can be used under Linux while another X session is running
on :0 (assuming the user can access the Linux console tty and mouse devices):
a new (blank) VC will be used for keyboard input on the local machine and the
Ctrl-Alt-F* sequence will be available to change to another VC (possibly back
to another X session running on the local machine). Using Ctrl-Alt-Backspace
on the blank VC will terminate the Xdmx session and return to the original VC.
This example uses the configuration file shown in the previous section: Xdmx :1 -input :0 +xinerama -configfile filename -config
example2
With this configuration file line:
option -input :0 +xinerama;
the command line can be shortened to:
Xdmx :1 -configfile filename -config example2
USING THE USB DEVICE DRIVERSThe USB device drivers use the devices called /dev/input/event0, /dev/input/event1, etc. under Linux. These devices are driven using the evdev Linux kernel module, which is part of the hid suite. Please note that if you load the mousedev or kbddev Linux kernel modules, then USB devices will appear as core Linux input devices and you will not be able to select between using the device only as an Xdmx core device or an Xdmx XInput extension device. Further, you may be unable to unload the mousedev Linux kernel module if XFree86 is configured to use /dev/input/mice as an input device (this is quite helpful for laptop users and is set up by default under some Linux distributions, but should be changed if USB devices are to be used with Xdmx).The USB device drivers search through the Linux devices for the first mouse, keyboard, or non-mouse-non-keyboard Linux device and use that device. KEYBOARD INITIALIZATIONIf Xdmx was invoked with -xkb or was not compiled to use the XKEYBOARD extension, then a keyboard on a backend or console will be initialized using the map that the host X server provides.If the XKEYBOARD extension is used for both Xdmx and the host X server for the keyboard (i.e., the backend or console X server), then the type of the keyboard will be obtained from the host X server and the keyboard under Xdmx will be initialized with that information. Otherwise, the default type of keyboard will be initialized. In both cases, the map from the host X server will not be used. This means that different initial behavior may be noted with and without XKEYBOARD. Consistent and expected results will be obtained by running XKEYBOARD on all servers and by avoiding the use of xmodmap on the backend or console X servers prior to starting Xdmx. If -xkbmap is specified on the Xdmx command line, then that map will currently be used for all keyboards. MULTIPLE CORE KEYBOARDSX was not designed to support multiple core keyboards. However, Xdmx provides some support for multiple core keyboards. Best results will be obtained if all of the keyboards are of the same type and are using the same keyboard map. Because the X server passes raw key code information to the X client, key symbols for keyboards with different key maps would be different if the key code for each keyboard was sent without translation to the client. Therefore, Xdmx will attempt to translate the key code from a core keyboard to the key code for the key with the same key symbol of the first core keyboard that was loaded. If the key symbol appears in both maps, the results will be expected. Otherwise, the second core keyboard will return a NoSymbol key symbol for some keys that would have been translated if it was the first core keyboard.SEE ALSODMX(3), X(7), Xserver(1), xdmxconfig(1), vdltodmx(1), xfs(1), xkbcomp(1), xkeyboard-config(7)AUTHORSKevin E. Martin <kem@redhat.com>, David H. Dawes <dawes@xfree86.org>, and Rickard E. (Rik) Faith <faith@redhat.com>.Portions of Xdmx are based on code from The XFree86 Project (http://www.xfree86.org) and X.Org (https://www.x.org).
Visit the GSP FreeBSD Man Page Interface. |