Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Xdmx(1)			    General Commands Manual		       Xdmx(1)

       Xdmx - Distributed Multi-head X server

       Xdmx [:display] [option ...]

       Xdmx  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 pro-
       tocol, and standard and/or commonly available X server extensions.

       In addition to the normal X server options described in the  Xserver(1)
       manual page, Xdmx accepts the following command line switches:

       -display	display-name
	       This  specifies the name(s) of the back-end X server display(s)
	       to connect to.  This option may be specified multiple times  to
	       connect	to  more than one back-end display.  The first is used
	       as screen 0, the	second as screen 1, etc.  If  this  option  is
	       omitted,	 the $DISPLAY environment variable is used as the sin-
	       gle back-end X server display.

       -xinput input-source
	       This specifies the source to use	for XInput extension  devices.
	       The  choices  are  the  same  as	 for -input , described	below,
	       except that core	devices	on backend servers cannot  be  treated
	       as  XInput  extension  devices.	(Although extension devices on
	       backend and console servers are supported as extension  devices
	       under Xdmx).

       -input input-source
	       This  specifies	the  source to use for the core	input devices.
	       The choices are:

		   A set of dummy core input drivers are  used.	  These	 never
		   generate any	input events.

		   The	raw  keyboard  and pointer from	the local computer are
		   used.  A  comma-separated  list  of	driver	names  can  be
		   appended.   For  example,  to select	the example Linux key-
		   board and PS/2 mouse	driver use: -input local,kbd,ps2.  The
		   following  drivers have been	implemented for	Linux: kbd, ms
		   (a two-button Microsoft mouse driver), ps2  (a  PS/2	 mouse
		   driver),  usb-mou (a	USB mouse driver), usb-kbd (a USB key-
		   board driver), and usb-oth (a USB  non-keyboard,  non-mouse
		   driver).   Additional  drivers  may	be  implemented	in the
		   future.  Appropriate	defaults will be used if no comma-sep-
		   arated list is provided.

		   If  the  display-name is a back-end server, then core input
		   events are taken from the server specified.	 Otherwise,  a
		   console window will be opened on the	specified display.

		   If the display-name is followed by ",xi" then XInput	exten-
		   sion	devices	on the display will be	used  as  Xdmx	XInput
		   extension  devices.	 If  the  display-name	is followed by
		   ",noxi" then	XInput extension devices on the	 display  will
		   not	be  used as Xdmx XInput	extension devices.  Currently,
		   the default is ",xi".

		   If the display-name is followed by ",console" and the  dis-
		   play-name  refers  to  a  display that is used as a backend
		   display, then a console window will be opened on that  dis-
		   play	and that display will be treated as a backend display.
		   Otherwise (or if ",noconsole" is used), the display will be
		   treated  purely  as	a  backend  or	a  console display, as
		   described above.

		   If the display-name is followed by  ",windows",  then  out-
		   lines  of  the  windows  on	the  backend will be displayed
		   inside the console window.  Otherwise (or  if  ",nowindows"
		   is  used), the console window will not display the outlines
		   of backend windows.	(This option only applies  to  console

		   If  the display-name	is followed by ",xkb", then the	next 1
		   to 3	comma-separated	parameters will	specify	the  keycodes,
		   symbols,  and  geometry  of	the  keyboard  for  this input
		   device.  For	 example,  ",xkb,xfree86,pc104"	 will  specify
		   that	 the "xfree86" keycodes	and the	"pc104"	symbols	should
		   be used to initialize the keyboard.	For an	SGI  keyboard,
		   ",xkb,sgi/indy(pc102)"  might  be  useful.	A list of key-
		   codes,  symbols,   and   geometries	 can   be   found   in
		   /usr/local/share/X11/xkb.   Use  of	keycodes,  symbols and
		   geometries for XKB configuration is deprecated in favor  of
		   the	rules,	layout,	 model,	 variant  and options settings
		   available via the -param  command  line  switch.   If  this
		   option  is not specified, the input device will be queried,
		   perhaps using the XKEYBOARD extension.

	       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.

	       This option turns off support for displaying  multiple  cursors
	       on  overlapped back-end displays.  This option is available for
	       testing and benchmarking	purposes.

	       This option sets	the Xdmx server's  default  font  path.	  This
	       option  can be specified	multiple times to accommodate multiple
	       font paths.  See	the FONT PATHS section below for  very	impor-
	       tant information	regarding setting the default font path.

       -configfile filename
	       Specify	the configuration file that should be read.  Note that
	       if the -display command-line option is used, then the  configu-
	       ration file will	be ignored.

       -config name
	       Specify a configuration to use.	The name will be the name fol-
	       lowing the virtual keyword in the configuration file.

       -stat interval screens
	       This option enables the display of performance statistics.  The
	       interval	 is  in	seconds.  The screens is a count of the	number
	       of back-end screens for which data is  printed  each  interval.
	       Specifying 0 for	screens	will display data for all screens.

	       For  each  screen,  the	following  information is printed: the
	       screen number, an absolute count	of the number of XSync() calls
	       made  (SyncCount),  the rate of these calls during the previous
	       interval	(Sync/s), the average round-trip  time	(in  microsec-
	       onds) of	the last 10 XSync() calls (avSync), the	maximum	round-
	       trip  time  (in	microseconds)  of  the	last  10  XSync	 calls
	       (mxSync),  the  average	number	of  XSync() requests that were
	       pending but not yet processed for each of the last 10 processed
	       XSync() calls, the maximum number of XSync() requests that were
	       pending but not yet processed for each of the last 10 processed
	       XSync()	calls, and a histogram showing the distribution	of the
	       times of	all of the XSync() calls that  were  made  during  the
	       previous	interval.

	       (The  length  of	the moving average and the number and value of
	       histogram bins are configurable at compile time	in  the	 dmxs-
	       tat.h header file.)

       -syncbatch interval
	       This  option  sets  the	interval  in  milliseconds for XSync()
	       batching.  An interval less than	or equal  to  0	 will  disable
	       XSync() batching.  The default interval is 100 ms.

	       This  option  disables  the  offscreen optimization.  Since the
	       lazy window creation optimization requires the offscreen	 opti-
	       mization	 to be enabled,	this option will also disable the lazy
	       window creation optimization.

	       This option disables the	lazy window creation optimization.

	       This option disables the	primitive subdivision optimization.

       -noxkb  Disable use of the XKB extension	 for  communication  with  the
	       back  end  displays.   (Combine	with -kb to disable all	use of

       -depth int
	       This option sets	the root window's default depth.  When	choos-
	       ing  a  default	visual	from those available on	the back-end X
	       server, the first visual	with that matches the depth  specified
	       is used.

	       This  option  can be combined with the -cc option, which	speci-
	       fies the	default	color visual class, to force the use of	a spe-
	       cific depth and color class for the root	window.

	       This option disables the	RENDER extension.

	       This  option  disables  GLX proxy -- the	build-in GLX extension
	       implementation that is DMX aware.

	       This option disables the	swap group and swap barrier extensions
	       in GLX proxy.

	       This  option  enables synchronization after a swap buffers call
	       by waiting until	all X protocol has  been  processed.   When  a
	       client  issues  a  glXSwapBuffers  request,  Xdmx  relays  that
	       request to each back-end	 X  server,  and  those	 requests  are
	       buffered	 along	with all other protocol	requests.  However, in
	       systems that have large network	buffers,  this	buffering  can
	       lead to the set of back-end X servers handling the swap buffers
	       request asynchronously.	With this option, an  XSync()  request
	       is issued to each back-end X server after sending the swap buf-
	       fers request.  The XSync() requests  will  flush	 all  buffered
	       protocol	 (including  the swap buffers requests)	and wait until
	       the back-end X servers have  processed  those  requests	before
	       continuing.   This  option  does	not wait until all GL commands
	       have been processed so there might be  previously  issued  com-
	       mands  that  are	 still being processed in the GL pipe when the
	       XSync() request returns.	 See the -glxfinishswap	 option	 below
	       if Xdmx should wait until the GL	commands have been processed.

	       This  option  enables synchronization after a swap buffers call
	       by waiting until	all GL commands	have been  completed.	It  is
	       similar	to  the	-glxsyncswap option above; however, instead of
	       issuing an XSync(), it issues  a	 glFinish()  request  to  each
	       back-end	X server after sending the swap	buffers	requests.  The
	       glFinish() request will flush all buffered  protocol  requests,
	       process	both  X	and GL requests, and wait until	all previously
	       called GL commands are complete before returning.

	       This option ignores font	paths that are not  available  on  all
	       back-end	 servers  by  removing	the  bad font path(s) from the
	       default font path list.	If no valid font paths are left	 after
	       removing	 the  bad paths, an error to that effect is printed in
	       the log.

	       This  option  enables  the  dynamic  addition  and  removal  of
	       screens,	 which is disabled by default.	Note that GLXProxy and
	       Render do not yet  support  dynamic  addition  and  removal  of
	       screens,	and must be disabled via the -noglxproxy and -norender
	       command line options described above.

       -param  This option specifies parameters	on  the	 command  line.	  Cur-
	       rently,	only  parameters  dealing with XKEYBOARD configuration
	       are supported.  These parameters	apply only to  the  core  key-
	       board.	Parameter  values  are installation-dependent.	Please
	       see /usr/local/share/X11/xkb or a similar  directory  for  com-
	       plete information.

		       Defaults	to "base".  Other values may include "sgi" and

		       Defaults	to "pc105".   When  used  with	"base"	rules,
		       other values may	include	"pc102", "pc104", "microsoft",
		       and many	others.	 When used  with  "sun"	 rules,	 other
		       values may include "type4" and "type5".

		       Defaults	to "us".  Other	country	codes and "dvorak" are
		       usually available.

		       Defaults	to "".

		       Defaults	to "".

       The 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-inte-
	      ger ]

	      origin ::= @ integer x integer

       The name	following virtual is used as an	identifier for the  configura-
       tion,  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 win-
       dow  on	the backend server.  The second	geometry, which	is always pre-
       ceeded 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  dis-
       play.)	The option line	is processed once at server startup, just line
       command line options.  This behavior may	be unexpected.

       Two 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; }
       A  4x4  wall  of	16 total displays could	be specified as	follows	(if no
       tiling dimension	is specified, an approximate square is used):
	      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;

       The 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 set-
       ting  the  Xdmx server's	default	font path with the -I "-fontpath" com-
       mand line option	described above.

       For example, if you specify a font  path	 with  the  following  command
	      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 exam-

       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	 +xin-
       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.

       The 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
	      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,kbd,ps2 +xin-
       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	termi-
       nate 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	 exam-
       With this configuration file line:
	      option -input :0 +xinerama;
       the command line	can be shortened to:
	      Xdmx :1 -configfile filename -config example2

       The  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

       If  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 key-
       board 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.

       X  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	infor-
       mation  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

       DMX(3),	X(7),  Xserver(1),  xdmxconfig(1),  vdltodmx(1),  xfs(1), xkb-
       comp(1),	xkeyboard-config(7)

       Kevin 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
       (	and X.Org (

X Version 11		      xorg-server 1.18.4		       Xdmx(1)


Want to link to this manual page? Use this URL:

home | help