| Available Languages: | English | Español | Français | 日本語 (Nihongo) | Português | Русский (Russkiy) | 中文 (简) (Simplified Chinese) | |
This document is about running X11 / XFree86 / Xtools on Apple's Mac OS X and Darwin systems. It gives an introduction and a history of development, then goes on to describe the current situation and the many options you have to use X11 with or without Fink.
The X Window System Version 11, or X11 for short, is a graphics display system with a network-transparent client-server architecture. It allows applications to draw pixels, lines, text, images, etc. on your screen. X11 also comes with additional libraries that let applications easily draw user interfaces, i.e. buttons, text fields, and so on.
X11 is the de facto standard graphics system in the Unix world. It comes with Linux, the *BSDs and most commercial Unix flavors. Desktop environments like CDE, KDE and GNOME run on top of it.
Mac OS X is an operating system produced by Apple. Like its predecessors NeXTStep and OpenStep, it is based on BSD and is thus a member of the Unix OS family. However, it comes with a proprietary graphics display system. The graphics engine is called Quartz and the look and feel is called Aqua, although the two names are often used intercheangably.
Darwin is basically a stripped-down version of Mac OS X that is available free of charge and with full source code. It does not contain Quartz, Aqua, or any other related technology. By default, it only offers a text console.
XFree86 is an open source implementation of X11. It was initially developed to run on Intel x86 PCs, hence the name. Nowadays, it runs on many architectures and operating systems, including OS/2, Darwin, Mac OS X and Windows.
Xtools is a product of Tenon Intersystems. It is a version of X11 for Mac OS X, based on XFree86.
Note: Development apparently stopped sometime before OS 10.3 was released.
X11 has a client-server architecture. There is one central program that does the actual drawing and coordinates access by several applications; that is the server. An application that wants to draw using X11 connects to the server and tells it what to draw. Thus applications are called clients in the X11 world.
X11 allows the server and the clients to be on different machines, which often results in confusion over the terms. In an environment with workstations and servers, you will run the X11 display server on the workstation machine and the applications (the X clients) on the server machine. So when talking about the "server", that means the X11 display server program, not the machine hidden in your wardrobe.
A little background: X11 models the screen as a hierarchy of windows contained in each other. At the top of the hierarchy is a special window which is the size of the screen and contains all other windows. This window contains the desktop background and is called the "root window".
Now back on topic: Like any graphical environment, X11 was written to stand alone and have full control over the screen. In Mac OS X, Quartz already governs the screen, so one must make arrangements if both are to get along together.
One arrangement is to let the two take turns. Each environment gets a complete screen, but only one of them is visible at a time and the user can switch between them. This is called full-screen or rooted mode. It is called rooted because there is a perfectly normal root window on the X11 screen that works like on other systems.
Another arrangement is to mix the two environments window by window. This eliminates the need to switch between two screens. It also eliminates the X11 root window, because Quartz already takes care of the desktop background. Because there is no (visible) root window, this mode is called "rootless". It is the most comfortable way to use X11 on Mac OS X.
In most graphical environments the look of window frames (title bar, close button, etc.) is defined by the system. X11 is different. With X11, the window frames (also called "decoration") are provided by a separate program, called the window manager. In most respects, the window manager is just another client application; it is started the same way and talks to the X server through the same channels.
There is a large number of different window managers to choose from. xwinman.org has a comprehensive list. Most popular ones allow the user to customize the appearance via so-called themes. Many window managers also provide additional functionality, like pop up menus in the root window, docks or launch buttons.
Many window managers have been packaged for Fink; here is a current list.
They are desktop environments, and there are many others. Their purpose is to provide additional framework to applications, so that their look, feel, and behaviour can be visually consistent. Example:
graphics engine : X11
window manager: sawfish
desktop: Gnome
The lines between graphics display engine, window manager, and desktop are blurred because similar, or the same functionality, may be implemented by one or more of them. This is one reason why a particular window manager may not be able to be used with a particular desktop environment.
Many applications are developed to integrate with a particular desktop. Most often by installing the libraries for the desktop environment (and the other underlying libraries) that an application was developed for, the application will work with limited or no function loss. Examples are the increasing selection of GNOME applications available to be installed and run without running GNOME. Unfortunately, the same progress is not quite yet able to be made with KDE applications.
[Sorry for the epic language, I couldn't resist...]
In the beginning, there was void. Darwin was in its infancy, Mac OS X was still in development and there was no X11 implementation for both of them.
Then there came John Carmack and ported XFree86 to Mac OS X Server, which was the only OS in the Darwin family available at that time. Later that port was updated for XFree86 4.0 and Darwin 1.0 by Dave Zarzycki. The patches found their way into the Darwin CVS repository and slept there, waiting for things to come.
One fine day Torrey T. Lyons came along and gave the Darwin patches the attention they had been waiting for. Finally, he brought them to a new home, the official XFree86 CVS repository. This was the time of the Mac OS X Public Beta and Darwin 1.2. XFree86 4.0.2 worked fine on Darwin, but on Mac OS X it required users to log out of Aqua and go to the console to run it. So Torrey gathered the XonX team around him and set out on a voyage to bring XFree86 to Mac OS X.
At about the same time Tenon started to build Xtools, using XFree86 4.0 as the foundation.
Soon the XonX team had XFree86 running in a fullscreen mode in parallel to Quartz and was putting out test releases for adventurous users. The test releases were called XFree86-Aqua, or XAqua for short. Since Torrey had taken the lead, changes went directly to XFree86's CVS repository, which was heading towards the 4.1.0 release.
In the first stages interfacing with Quartz was done via a small application called Xmaster.app (written with Carbon, then rewritten with Cocoa). Later that code was integrated into the X server proper, giving birth to XDarwin.app. Shared library support was also added at this time (and Tenon was convinced to use this set of patches instead of their own to ensure binary compatibility). There was even good progress on a rootless mode (using the Carbon API), but alas, it was too late to get it into XFree86 4.1.0. And the rootless patch was free, and continued to float around the net. After XFree86 4.1.0 shipped with just the fullscreen mode, work on the rootless mode continued, now using the Cocoa API. An experimental rootless mode was put into XFree86's CVS repository.
In the meantime, Apple released Mac OS X 10.0 and Darwin 1.3, and Tenon released Xtools 1.0 some weeks after that.
Development continued on integrating the rootless mode into XFree86, so that by the time XFree86 4.2.0 shipped in January 2002, the Darwin/Mac OS X version had been completely integrated into the main XFree86 distribution.
Fink will let you install X11 in a variety of ways, among these it provides XFree86 packages of its own. If you use fink install ..., it will download the source code and compile it on your computer. If you use apt-get install ... or the dselect frontend, it will download precompiled binary packages, similar to the official XFree86 distribution.
General notes:
You can go the other way though: packages built vs an older X11 generally work on a later one.
For 10.3 or 10.4, the X11 hierarchy (newer -> older codebases) is as follows:
xorg > xfree86 > Apple's X11
10.4 users:
You can install XFree86 version 4.5.0-23 from source. You will need both the xfree86 and xfree86-shlibs packages to have a fully functional installation.
You can also install the X.org X11 release (currently version 6.8.2-35) via the xorg and xorg-shlibs packages in the unstable tree. This X11 flavor is similar to XFree86-4.5, but includes some bugfixes and new features, and removes some code with a disputed license.
10.3 users:
You can install XFree86 version 4.4.0-13 (that which is in the current binary distribution) or 4.5.0-13 (which is available from source). You will need both the xfree86 and xfree86-shlibs packages to have a fully functional installation.
You can also install X.org-6.8.2 via the xorg and xorg-shlibs packages as above.
10.2 users:
10.2 users may install version 4.3 via source or binary, and 4.4 from the unstable tree. As above, you'll install xfree86 and xfree86-shlibs.
XFree86 4.2.1.1 is also available for 10.2, in normal and -threaded flavors (later X11s all have threading support), though it is considered to be obsolete. The xfree86-base, xfree86-base-shlibs, xfree86-shlibs, and xfree86-rootless-shlibs packages (or their -threaded counterparts must all be installed for you to have a working XFree86 setup. In addition, you may need to install the xfree86-base-dev and xfree86-rootless-dev packages (or their -threaded equivalents) to keep Fink from trying to install a newer version.
10.1 users:
You can install version 4.2.0 from the binary distribution (only). You will install xfree86-base and xfree86-rootless.
On January 7, 2003, Apple released a custom X11 implementation based on XFree86-4.2 which includes Quartz rendering and accelerated OpenGL. A new version was released on February 10, 2003 with additional features and bugfixes. A third release (i.e. Beta 3) was made on March 17, 2003 with further additional features and bugfixes. This version is usable on Jaguar.
On October 24, 2003, Apple released Panther (10.3), which includes a release version of their X11 distribution. This version is based on XFree86-4.3.
On April 29, 2005, Apple released Tiger (10.4), which includes a release version of Apple's X11 based on XFree86-4.4.
To use the Apple binaries, you need to make sure the X11 User package is installed, and you should also update Fink.
Under fink-0.16.2, you will need to install the X11 SDK package, as well. After you do this, Fink will create a system-xfree86 virtual package.
Under fink-0.17.0 and later installing the X11 SDK is only necessary if you want to build packages from source. In this case, even if you don't have the SDK, there will be system-xfree86 and system-xfree86-shlibs virtual packages, the latter representing the shared libraries. If you do install the SDK, there will also be a system-xfree86-dev package, representing the headers.
If you have an existing XFree86 distribution installed, be it through Fink or otherwise, you can follow the instructions on replacing one X11 package with another. Make sure that you remove your existing packages, then install Apple's X11 (and X11 SDK, if needed or desired).
Some notes on using Apple's X11:
The autocutsel package is no longer needed. If you're starting X11 with it enabled, you should disable it.
Apple's X11 uses your existing ~/.xinitrc file. If you want the full effect of Quartz integration, you should use /usr/X11R6/bin/quartz-wm as your window manager, or delete your ~/.xinitrc completely.
If you just want cut-and-paste integration, but want to use a different window manager, you can do this as in the following example:
/usr/X11R6/bin/quartz-wm --only-proxy & exec /sw/bin/fvwm2
You may, of course, call any other window manager, startkde, etc.
quartz-wm doesn't fully support Gnome/KDE window manager hints, so you may see some strange behavior on windows that shouldn't have decorations, but do.
Apple X11 doesn't honor the Fink environment settings by default. In order to call up startup applications that you have installed with fink (e.g. window managers, gnome-session, other apps under /sw/bin) put the following near the top of ~/.xinitrc (i.e. after the initial "#!/bin/sh", but before you run any programs):
. /sw/bin/init.sh
so that the Fink environment is initialized. Note: init.sh is used rather than init.csh because .xinitrc is run by sh rather than tcsh.
Applications that require calling other programs which reside within your Fink tree for some of their functions need special treatment to get them to work when called from the Application menu. Instead of putting just the full path to the filename, e.g.
/sw/bin/emacs
you'll want to use something like the following, if you're using bash as your default shell:
. /sw/bin/init.sh ; emacs
and if you're using tcsh:
source /sw/bin/init.csh ; emacs
This makes sure that the application has the correct PATH information. You can use this syntax for any Fink-installed application.
If you are trying to build a package by hand against Apple's X11 and you see a failure like:
ld: err.o illegal reference to symbol: _XSetIOErrorHandler defined in indirectly referenced dynamic library /usr/X11R6/lib/libX11.6.dylib
then you'll need to make sure to that -lX11 is present during linking. Check your package's configuration options to see how to feed it the extra argument.
If you use the xfree86 package, and later switch to Apple's X11 (on either 10.2.x or 10.3.x), any packages you have built against xfree86 will need to be rebuilt, as the binaries are incompatible.
10.3 and 10.4 users only: It is possible to use Apple's display server and window manager on top of XFree86 or X.org. If you install the applex11tools package, Fink will install what you need, as long as you have a copy of X11User.pkg.
For more information on using Apple's X11, check out this article at the Apple Developer Connection.
The XFree86 project has an official binary distribution of XFree86 4.5.0. You can find it on your local XFree86 mirror in the directory 4.5.0/binaries/Darwin-ppc-6.x (or 4.5.0/binaries/Darwin-ppc-5.x for OS 10.1). Be sure to get the Xprog.tgz and Xquartz.tgz tarballs even though they are marked as "optional". If you're unsure what you need, just download the whole directory. Run the Xinstall.sh script as root to install the stuff. (You might want to read the official instructions before installing.)
You've now got XFree86 with a server that can do fullscreen, or rootless under Mac OS X.
If you've got the time to spare, you can build XFree86 4.5 from source. You can find the source on your local XFree86 mirror in the directory 4.5.0/source. Grab all seven XFree86-4.5.0-src-#.tgz tarballs and extract them in the same directory. You can customize the build by putting macro definitions in the file config/cf/host.def in the XFree86 source tree. See config/cf/darwin.cf for some hints. (Note: Only the macros that have an #ifndef check around them can be overwritten in host.def.)
When you're happy with your configuration, compile and install XFree86 with the following commands:
make World sudo make install install.man
As with the official binaries, you've now got XFree86 with a server that can do fullscreen, or rootless under Mac OS X.
If you have not only time, but also some nerves to spare you can get the latest development version of XFree86 from the public CVS repository. Note that the code is under constant development; what you get today is usually not the same as what you got yesterday.
To install, follow the XFree86 CVS instructions to download the xc module. Then, follow the source build instructions above.
If you have already installed one of the Fink X11 packages but for one reason or another have decided you need to remove one and replace it with another, the procedure is pretty straightforward. You will have to force a removal of the old packages, and then install the new, to keep your dpkg database consistent.
There are two different ways to do this:
Use FinkCommander
If you are using FinkCommander, you can force removal through the menu. For example, if you have xfree86-rootless installed, but want the threaded version, you can select your xfree86-rootless, xfree86-rootless-shlibs, xfree86-base, and xfree86-base-shlibs packages, and then run:
Source -> Force Remove
Manually Remove from the Command-Line
To manually, remove them, you use the dpkg with the --force-depends option, like so:
sudo dpkg -r --force-depends xfree86-rootless\ xfree86-rootless-shlibs xfree86-base xfree86-base-shlibs
Note that if you have apps that require threaded XFree86, you may have trouble with your dpkg database if you force remove it and install a different XFree86 package or placeholder package.
If, on the other hand, you have an X11 version that was not installed via Fink, you'll need to remove it via the command line:
sudo rm -rf /usr/X11R6 /etc/X11
The above holds true for removing any flavor of X11 that you didn't install through Fink. You will also need to remove XDarwin.app | X11.app, depending on what you had installed. Make sure to check your .xinitrc if you are removing Apple's X11 to make sure that you aren't trying to run quartz-wm. You can now install whatever new X11 variety you want, manually or via Fink.
A quick summary of the install options and the Fink packages you should install:
| Install Type | Fink packages |
|---|---|
| XFree86-4.4.0 or 4.5.0 (10.3 and 10.4) |
xfree86 and xfree86-shlibs |
| X.org-6.8.2 (10.3 and 10.4) |
xorg and xorg-shlibs |
| Apple's X11 (all versions) |
system-xfree86 and system-xfree86-shlibs (+system-xfree86-dev for building X11-based packages) |
| XFree86-4.x official binaries |
system-xfree86 and system-xfree86-shlibs (+system-xfree86-dev for building X11-based packages) |
| XFree86-4.x built from source, or from the latest CVS source |
system-xfree86 and system-xfree86-shlibs (+system-xfree86-dev for building X11-based packages) |
| XFree86-4.2.1.x (10.2 only) or 4.2.0 (10.1 only) |
xfree86-base and xfree86-rootless (and their -shlibs) or xfree86-base-threaded and xfree86-rootless-threaded (and -shlibs) |
On pure Darwin, XFree86 behaves like on any other Unix. The usual way to start it is via startx from the console; that starts both the server and some initial clients like the window manager and a terminal emulator with a shell. On pure Darwin it is not necessary to specify any parameters, so you can just type:
startx
You can customize what is started through several files in your home directory. .xinitrc controls what clients get started. .xserverrc controls server options and may even start a different server. If you're having trouble (as in, you only get a blank screen or XFree86 drops you right back to the console), you can start troubleshooting by moving these files out of the way. When startx doesn't find these files, it will use safe defaults that should always work.
Alternatively, you can start the server directly with one of the XDMCP options, like this:
X -query remotehost
Details about this can be found in the Xserver manual page.
Finally, there is the option to set up xdm; read its manual page for details.
Note: If you're running Mac OS X anterior to Panther, you can type >console at the login window and you'll get a text console that is equivalent to pure Darwin. In case you don't see a field to enter a user's name in the login window, just type the first letter of whichever user's name, following by option-return. You can use all of the start methods outlined above, with the exception of xdm.
Note: If you are running Mac OS X Panther or later, you cannot start XFree86 from the console window.
There are basically two ways to start XFree86 under Mac OS X. One is double-clicking the XDarwin.app application in your Applications folder. This will let you choose between full screen and rootless mode in a dialog at startup. You can disable the dialog and set XDarwin always to use the mode of your choice in the Preferences dialog.
Prior to 4.2.0 it would fire up fullscreen mode automatically, and there was no way to get rootless mode by double-clicking the application.
The other way to start XFree86 under Mac OS X is via startx from Terminal.app. If you start the server this way, you must tell it that it should run in parallel with Quartz. You do this by passing the -fullscreen option, like this:
startx -- -fullscreen
That will start up the server in fullscreen mode, plus the clients in your .xinitrc.
NOTE: prior to 4.2, -quartz was used for fullscreen mode.
You can start it in rootless mode with the -rootless option:
startx -- -rootless
The -quartz option no longer selects fullscreen mode, but rather uses the default mode set in the preferences.
As of version 4.3, if you use startx without arguments, the startup dialog box will come up.
X.org works identically to XFree86 in all respects.
Functionally, Apple's X11 works similarly to XFree86 (e.g. using a .xinitrc file to control the clients that are launched on startup). The normal way to run it is by double-clicking the X11.app icon (whose default location is /Applications/Utilities). You can use startx, as well, but it doesn't have a commmand-line option to set the display mode; X11.app will start up in whatever mode was previously set in its Preferences.
If you don't set up a different window manager you will be running Apple's quartz-wm window manager. X11.app's Preferences give the option to switch between fullscreen and rootless modes without restarting. However, this doesn't work for quartz-wm; it is necessary to choose a different window manager (e.g. in .xinitrc)
Fink's applex11tools package allows the use of X11.app and quartz-wm under OS 10.3 and later with XFree86 4.4 or later or X.org.
To install this package you must enable the unstable tree, and have X11User.pkg somewhere within /Users or /Volumes. X11.app will be installed in the Applications folder within your Fink tree. You can now use either X11.app or XDarwin.app.
If a file named .xinitrc exists in your home directory, it will be used to start some initial X clients, e.g. the window manager and some xterms or a desktop environment like GNOME. The .xinitrc file is a shell script that contains the commands to do this. It is not necessary to put the usual #!/bin/sh in the first line and to set the executable bit on the file; xinit will still know how to run it through a shell.
When there is no .xinitrc file in your home directory, X11 will use its default file, /private/etc/X11/xinit/xinitrc. You can use the default file as a starting point for your own .xinitrc:
cp /private/etc/X11/xinit/xinitrc ~/.xinitrc
If you're using Fink, you should source init.sh right at the beginning to make sure the environment is set up correctly.
You can put fairly arbitrary commands in an .xinitrc, but there are some caveats. First, the shell that interprets the file will by default wait for every program to finish before it starts the next one. If you want several programs to run in parallel, you must tell the shell to put them "in the background" by adding a & at the end of the line.
Second, xinit waits for the .xinitrc script to finish and interprets that as "the session has ended, I should kill the X server now, too". This means that the last command of your .xinitrc must not be run in the background and it should be a long-living program. Customarily, the window manager is used for this purpose. In fact, most window managers assume that xinit is waiting for them to finish and use this to make the "Log out" entry in their menus work. (Note: To save some memory and CPU cycles, you can put an exec before the last line like in the examples below.)
A simple example that starts up GNOME on XFree86 or Xorg:
. /sw/bin/init.sh exec gnome-session
A more complex example for bash users that turns the X11 bell off, starts some clients and finally executes the Enlightenment window manager:
. /sw/bin/init.sh xset b off xclock -geometry -0+0 & xterm & xterm & exec enlightenment
To start GNOME 2.4 and later under Apple's X11:
. /sw/bin/init.sh quartz-wm --only-proxy & exec gnome-session
To start KDE 3.2 (version < 3.2.2-21) under Apple's X11
. /sw/bin/init.sh export KDEWM=kwin quartz-wm --only-proxy & /sw/bin/startkde >/tmp/kde.log 2>&1
And finally to start the latest unstable version of KDE under Apple's X11:
. /sw/bin/init.sh /sw/bin/startkde >/tmp/kde.log 2>&1
OroborOSX is an alternative to the X11.app and XDarwin display servers. It requires a preexisting X11 installation to work. X11.app or XDarwin.app continue to function, as well
When run, OroborOSX starts its own rootless-only window manager, and doesn't read in either the system's xinitrc or user's .xinitrc files. After starting, it does have a menu option to execute .xinitrc. However, it does have its own method to set up applications to run when it starts. It also provides a mechanism to start X11 applications from the Finder via startup scripts.
For more information visit the OroborOSX homepage.
Now that's easy for a change. Get the installer, double-click it, and follow the instructions. Be sure to select the startup volume when asked.
If you're using Fink, you should install the system-xtools package after you've installed Xtools. That package will not install any files, it will just check that the libraries etc. are there and act as a placeholder in Fink's dependency system.
To run Xtools, double-click Xtools.app in your Applications folder. Like XFree86, Xtools will run the clients you specify in your .xinitrc file. Xtools additionally allows you to start clients via the menu.
Xtools does hardware-accelerated OpenGL in rootless mode and comes with the libraries to support it. While the main libGL library is fine, the libGLU and libglut libraries are only present as static libraries, which is not sufficient for full binary compatibility with XFree86. Also, some headers are missing. Fink doesn't offer a workaround at this time. Hopefully this will be fixed in Xtools 1.1 once it is released.
VNC is a network-capable graphics display system similar in design to X11. However, it works at a lower level, making implementation easier. With the Xvnc server and a Mac OS X display client, it is possible to run X11 applications with Mac OS X. Jeff Whitaker's Xvnc page has more information on that.
WiredX is an X11 server written in Java. It also supports rootless mode. An Installer.app package is available at the web site.
According to the website, eXodus 8 by Powerlan USA runs natively on Mac OS X. It is unknown what codebase it uses and whether/how it supports local clients. Because of this, there is no special support for eXodus in Fink. If you have more info, please throw it our way.
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.
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.
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
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.
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:
Just ignore the messages.
Get rid of the messages by unsetting the environment variable LANG. Note that this will also turn internationalization off in programs that actually support it (via gettext/libintl). Example for .xinitrc:
unset LANG
Example for .cshrc:
unsetenv LANG
(10.1 only) Use the libxpg4 Fink package. It builds a small library that contains working locale functions and arranges that it is loaded before the system libraries (using the DYLD_INSERT_LIBRARIES environment variable). You may have to set the LANG environment variable to a fully qualified value, e.g. de_DE.ISO_8859-1 instead of de or de_DE.
Ask Apple to include proper locale support in a future version of Mac OS X.
To launch X11 applications from a Terminal.app window, you must set the environment variable "DISPLAY". This variable tells the applications where to find the X11 window server. In the default setup - XDarwin runs on the same machine -, you can set the variable as follows:
For tcsh users:
setenv DISPLAY :0.0
For bash users:
export DISPLAY=":0.0"
A nice setup is to have XDarwin.app started when you log in (settable in the Login panel of the System Preferences on Mac OS 10.2, in the Accounts panel, Startup items on Mac OS 10.3):
For tcsh users, add the following to your .cshrc file:
if (! $?DISPLAY) then setenv DISPLAY :0.0 endif
For bash users, add the following to your .bashrc file:
[[ -z $DISPLAY ]] && export DISPLAY=":0.0"
This sets DISPLAY automatically in every shell. It doesn't override the current value when DISPLAY is already set, though. This way you can still run X11 applications remotely or through ssh with X11 tunneling.
One way to launch Aqua applications from an xterm (or any other shell, actually) is the open command. Some examples:
open /Applications/TextEdit.app open SomeDocument.rtf open -a /Applications/TextEdit.app index.html
The second example opens the document in the application that is associated with it, the third example explicitly gives an application to use.
Copy and Paste generally works between the Aqua and X11 environments. There are still some bugs. Emacs is reported to be picky about the current selection. Copy and paste from Classic to X11 doesn't work.
Anyway, the trick is to use the respective methods of the environment you're in. To transfer text from Aqua to X11, use Cmd-C in Aqua, then bring the destination window to the front and use the "middle mouse button", i.e. Option-click on a single-button mouse (this can be configured under XDarwin's Preferences), to paste. To transfer text from X11 to Aqua, simply select the text with the mouse in X11, then use Cmd-V in Aqua to paste it.
The X11 system actually has several separate clipboards (called "cut buffers" in X11 speak), and some applications have weird views which one should be used. In particular, pasting into GNU Emacs or XEmacs sometimes doesn't work because of this. The program autocutsel can help here; it automatically synchronizes the two main cut buffers. To run it, install the autocutsel Fink package and add the following line to your .xinitrc:
autocutsel &
(Make sure it's before the line that exec's the window manager and never returns! Don't just add it at the end, it won't be executed.) And remember that it is no more necessary for Apple's X11 (see Some notes on using Apple's X11).
If you are using Apple's X11, then you can use Command-C or Edit->Copy, as usual for Mac apps, to copy text to the clipboard, and the middle-mouse button or Command-V to paste from the clipboard to Apple X11.
In any case, if you encounter problems copying or pasting from Aqua to X11 and vice-versa, you may first try to do the pasting part twice (it may happen that the copy does not occur at once), then use intermediate applications, e.g. TextEdit or Terminal.app on the Aqua side, nedit or an xterm on the X11 side. In my experience, there is always a solution.
Copyright (c) 2001 Christoph Pfisterer, Copyright (c) 2001-2010 The Fink Project. You may distribute this document in print for private purposes, provided the document and this copyright notice remain complete and unmodified. Any commercial reproduction and any online publication requires the explicit consent of the author.
Generated from $Fink: x11.en.xml,v 1.22 2007/08/15 21:57:04 dmacks Exp $