Fink

Running X11 - 7. Troubleshooting XFree86

7.1 When I launch XDarwin, it quits or crashes almost immediately

First of all: Don't Panic! There are lots of things than can go wrong with XFree86, and a good number of them can cause startup failures. Further, it is not unusual that XDarwin crashes when it experiences startup problems. This section tries to provide a comprehensive list of problems you may come across. But first, you need to gather two important pieces of information:

XDarwin version. You can find the XDarwin version in the Finder by clicking once on the XDarwin icon and then selecting "Show Info" from the menu. The version is only incremented when a new binary test release is made by the XonX project, so "1.0a1" may actually be any version between 1.0a1 and 1.0a2.

Error messages. These are essential in pinpointing the particular problem you experience. How you get the error messages depends on how you started XDarwin. If you ran startx from a Terminal window, you'll have the messages right there in that window. Remember that you can scroll up. If you started XDarwin by double-clicking the icon, the messages end up in the system log, which you can access through the Console application in the Utilities folder. Be sure to pick the right set of messages, i.e. the last one.

We'll start with a list of the messages you may see: 

_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root

Class: Harmless. X11 creates hidden directories in /tmp to store the socket "files" for local connections. For security reasons, X11 prefers if these directories are owned by root, but since they are world-writable anyway it will still run without any problems. (Note: It's quite hard to have these dirs owned by root, as Mac OS X wipes out /tmp on reboots and XDarwin doesn't run with root privileges and doesn't need to.) 

QuartzAudioInit: AddIOProc returned 1852797029
-[NSCFArray objectAtIndex:]: index (2) beyond bounds (2)
kCGErrorIllegalArgument : CGSGetDisplayBounds (display 35434400)
No core keyboard

Class: Bogus. These are follow-up errors that result when the server tries to reset itself after a previous error. During that, another copy of the startup banner is printed, followed by one or more of the above messages because resetting the server doesn't really work in the affected versions of XDarwin. So when you see messages like these, scroll up in the Terminal resp. Console window and look for another set of banner and messages. This affects all versions up to and including XDarwin 1.0a3; it was fixed after 1.0a3 was released. 

cat: /Users/chrisp/.Xauthority: No such file or directory

Class: Mostly harmless. It is unknown where these messages come from and they seem to have no impact on operations. You can get rid of them by running touch .Xauthority in your home directory. 

Gdk-WARNING **: locale not supported by C library

Class: Harmless. This just means what it says and won't keep the application from working. For more information, see below. 

Gdk-WARNING **: locale not supported by Xlib, locale set to C
Gdk-WARNING **: can not set locale modifiers

Class: Bad, but not fatal. These messages may appear in addition to the one above. This indicates that XFree86's locale data files are not present. It appears that this happens unreproducibly when building Free86 from source. Most applications will still work, GNU Emacs is a notable exception. 

Unable to open keymapping file USA.keymapping.
Reverting to kernel keymapping.

Class: Often fatal. This can happen with XDarwin 1.0a1, with the "Load from file" keymapping option enabled. That version needs a full path when the file to load is set via the Preferences dialog, but searches automatically when it is passed on the command line. The message will usually be followed by the "assert" message shown below. To fix this, follow the directions below. 

Fatal server error:
assert failed on line 454 of darwinKeyboard.c!
Fatal server error:
Could not get kernel keymapping! Load keymapping from file instead.

Class: Fatal. Changes Apple made in Mac OS X 10.1 broke the code in XFree86 that reads the keyboard layout from the operating system kernel; the message above is the result of that. You must use the "Load from file" keymapping option on Mac OS X 10.1. The setting is in the XDarwin Preferences dialog. Be sure that a file is selected (i.e. use the "Pick file" button) - simply activating the check box may not be sufficient with some versions of XDarwin. If you can't get to the Preferences dialog because XDarwin closes before you get a chance, run it from Terminal with the command startx -- -quartz -keymap USA.keymapping. This usually allows XDarwin to start up, and you can then make the permanent choice in the Preferences dialog. 

Fatal server error:
Could not find keymapping file .

Class: Fatal (as it says). This error is due to the absence of the keymapping files under Panther. You need to install xfree86-4.3.99-16 or later, since these versions don't need the keymapping files.

Warning: no access to tty (Inappropriate ioctl for device).
Thus no job control in this shell.

Class: Mostly harmless. XDarwin 1.0a2 and later launch an interactive shell behind the scenes to run your client startup file (.xinitrc). This was done so that you don't have to add statements to set up PATH in that file. Some shells complain that they're not connected to a real terminal, but that can be ignored since that shell instance is not used for anything that requires job control or the like. 

Fatal server error:
failed to connect as window server!

Class: Fatal. This means that the console-mode server (for pure Darwin) got started while you were logged into Aqua. Usually this happens when you installed the official XFree86 binary distribution and left out the Xquartz.tgz tarball. It can also happen when the symlinks in /usr/X11R6/bin are messed up or when you issue the command XDarwin in a Terminal window to start the server (you should use startx instead in that case, see Starting XFree86).

In any case, you can run ls -l /usr/X11R6/bin/X* and check the output. You should see four relevant entries: X, a symlink pointing at XDarwinStartup; XDarwin, an executable file (this is the console mode server); XDarwinQuartz, a symlink pointing at /Applications/XDarwin.app/Contents/MacOS/XDarwin; and XDarwinStartup, a small executable file. If any of these are missing or pointing at different files, you need to fix that. How you do that depends on the method you used to install XFree86. If you installed XFree86 with Fink then you need to reinstall the xfree86 package (or xfree86-rootless for OS 10.2 and earlier). If you installed it by yourself, then get the files from a copy of Xquartz.tgz. 

The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error:            Can't find file "unknown" for geometry include
>                   Exiting
>                   Abandoning geometry file "(null)"
Errors from xkbcomp are not fatal to the X server

Class: Mostly harmless. As the message says, it is not fatal. To my knowledge, XDarwin doesn't use the XKB extension at all. Probably some client program tries to use it anyway... 

startx: Command not found.

Class: Fatal. This can happen with XDarwin 1.0a2 and 1.0a3 when your shell initialization files are not set up to add /usr/X11R6/bin to the PATH variable. If you use Fink and haven't changed your default shell, adding the line source /sw/bin/init.csh to .cshrc in your home directory (as recommended by the Fink instructions) should be sufficient. 

_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
Fatal server error:
Cannot establish any listening sockets - Make sure an X server isn't already
running

Class: Fatal. This can happen when you accidentally run several instances of XDarwin at once, or maybe after an unclean shutdown (i.e. crash) of XDarwin. It might also be a file permission problem with the sockets for local connections. You can try to clean that up with rm -rf /tmp/.X11-unix. Restarting the computer also helps in most cases (Mac OS X automatically cleans up /tmp when it boots, and the network stack is reset). 

Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server

Class: Fatal. The client programs can't connect to the display server (XDarwin) because they use bogus authentication data. This can be caused by some VNC installations, by running XDarwin through sudo, and probably some other freak accidents. The usual fix is to delete the .Xauthority file (which stores the authentication data) in your home directory and re-create an empty file: 

cd
rm .Xauthority
touch .Xauthority

Another common cause for XFree86 startup failures is an incorrect .xinitrc file. What happens is that the .xinitrc is run and for some reason terminates almost immediately. xinit interprets this as "the user's session has ended" and kills XDarwin. See the .xinitrc section for more details. Remember to set up the PATH and to have one long-lived program that is not started in the background. It is a good idea to add exec xterm as a fallback when your window manager or similar can't be found.

7.2 Black icons in the GNOME panel or in the menu of a GNOME application

A common problem is that icons or other images are displayed as black rectangles or black outlines. Ultimately, this is caused by limitations in the operating system kernel. The problem has been reported to Apple, but so far they seem unwilling to fix it; see the filed Darwin bug report for details.

The current situation is that the MIT-SHM extension of the X11 protocol is practically unusable on Darwin and Mac OS X. There are two ways to turn the protocol extension off: in the server or in the clients. The XFree86 servers installed by Fink (i.e. the xfree86-server and xfree86-rootless packages) have it turned off. The GIMP and the GNOME panel have been inoculated as well. If you experience black icons in another application, start that application with the --no-xshm command line option.

7.3 The keyboard doesn't work in XFree86

This is a known problem that so far seems to affect only portables (PowerBook, iBook). To work around this, the "Load from file" keymapping option was implemented. Nowadays it has become the default because the old method (reading the mapping from the kernel) stopped working with Mac OS X 10.1. If you haven't enabled the option already, you can do so in the XDarwin preferences dialog. Check the "Load from file" checkbox and select the keymapping file to load. After restarting XDarwin, your keyboard should mostly work (see below).

If you're starting XFree86 from the command line, you can pass the name of the keymapping file to load as an option, as in: 

startx -- -quartz -keymap USA.keymapping

7.4 The Backspace key doesn't work

This can happen when you use the "Load keymapping from file" option described above. The mapping files describe the backspace key as "Delete", not as "Backspace". You can correct that by putting the following line in your .xinitrc file: 

xmodmap -e "keycode 59 = BackSpace"

If I remember correctly, XDarwin 1.0a2 and later have code that correctly maps the Backspace key automatically.

7.5 "Warning: locale not supported by C library"

These messages are quite common, but harmless. It just means what it says - internationalization is not supported through the standard C library, the program will use the default English messages, date formats, and so on. There are several ways to deal with this:

Next: 8. Usage Tips