This is a summary of Frequently Asked Questions for the Distributed Multi-head X project: http://dmx.sourceforge.net. Id: $Id: FAQ,v 1.5 2003/08/19 21:01:40 faith Exp $ Q1. When a client tries to connect to the Xdmx server, the following errors are seen FROM THE CLIENT: Xlib: connection to "machine:1.0" refused by server Xlib: No protocol specified A1. These are standard X authority errors and are independent of the Xdmx server. Look for problems in the following areas: 1) Is the XAUTHORITY environment variable set? 2) Is the XAUTHORITY environment variable set incorrectly? Solutions: 1) The brute force way to avoid these errors is to pass Xdmx the -ac flag on the command line. This is the equivalent of "xhost +" and defeats all X authentication security mechanisms. You should use -ac FOR TESTING ONLY and never for production installations. 2) Start your Xdmx session with a command that will properly set up the X authority system: startx -- /path/to/bin/Xdmx :1 +xinerama -display cr1:0 -display cr2:0 Q1A. When a client tries to connect to the Xdmx server, the following error is seen FROM THE XDMX SERVER: AUDIT: : Xdmx: client 1 rejected from local host A1A. This means you started Xdmx with the XAUTHORITY environment variable set and/or with the -auth option, and you are not sharing (or have not created!) the magic cookie for the Xdmx display. E.g., if you started Xdmx with "Xdmx :1", then the Xdmx server and the client will both use the cookie associated with ":1". Q2. When I maximize a window in Gnome, it only covers one backend display, not the whole Xdmx desktop. A2. This is a feature of the underlying "xinerama-aware" window manger that Gnome is using and has nothing to do with Xdmx. You should try another window manager that is either not xinerama-aware, or that has configurable xinerama support. If anyone has suggestions, please submit them to the dmx-devel list. Q3. What tags are available in the CVS repository and what are they for? A3. These are the tags that users of Xdmx will be interested in (most recent first, with FINAL indicating a stable "delivery" version and WIP indicating a Work In Progress): dmx-1-0-20030731-final Phase IV FINAL dmx-1-0-20030627-beta Phase IV Beta dmx-1-0-20030530-alpha Phase IV Alpha dmx-1-0-20030331-snapshot Phase IV WIP snapshot dmx-20030306-postmerge Phase IV WIP after XFree86 4.3.0 merge dmx-20030305-premerge Phase IV WIP before XFree86 4.3.0 merge dmx-1-0-20030129-snapshot Phase IV WIP snapshot dmx-20021222-phase3 Phase III FINAL (from dri.sf.net CVS tree) These tags will be interesting only to CVS repository maintainers: dmx-20021222-base Prior to Phase III merge (no Xdmx here) xfree86-4-3-0 Import of XFree86 4.3.0 xfree86-20021213 Import of an XFree86 snapshot prior to 4.3.0 XFREE86 Vendor branch for our XFree86 imports Q4. Why, when I start Xdmx, do I see the following error? The DMX server failed to set the font path on the back-end servers The font path that the DMX server tried to set was: /usr/X11R6/lib/X11/fonts/misc/ /usr/X11R6/lib/X11/fonts/Speedo/ /usr/X11R6/lib/X11/fonts/Type1/ /usr/X11R6/lib/X11/fonts/75dpi/ /usr/X11R6/lib/X11/fonts/100dpi/ Please see the Xdmx man page for information on how to initialize the DMX server's font path with "-fontpath" A4. If you are running XFree86, this is probably because the backend server has rejected one of these fonts. Perhaps you modified the backend FontPath, but forgot to load the the appropriate module (e.g., the "type1" and "freetype" modules are often listed in a default XF86Config file, but "speedo" may not be). If that is not the problem, then you should note that all of the backend servers must have EXACTLY the same fonts available. There are 4 options to ensure this: 1) Use the default font path and make sure that the contents of /usr/X11R6/lib/X11/fonts are identical across all machines, perhaps by NFS mounting the directory from a single source. 2) Use an explicit font path and make sure that all of the directories listed have identical contents across all machines. 3) Use local font servers (also specified in the font path), and make sure that all of the local font servers are configured identically. 4) Use a single font server, specified using the Xdmx -fontpath and in the /etc/X11/XF86Config file on each backend server. If you select any of the first 3 options, and if the directories ever get out of sync, Xdmx may not start, may have errors, or may render fonts differently on different backend machines. Examples are given in the FONT PATHS section of the Xdmx man page.