Introduction

19 Nov 2007

Most of the following content has been extracted from Ben Byer's posts in the last couple of months to Apple's X11-users Mailing List.

X11 in Leopard syncs up with Xorg 7.2. The developers switched from the XFree86 codebase (based on IIRC, X11R6.8) to the X.org codebase (X11R7.2). It now installs by default. You can choose not to install it by clicking customize during the Leopard installation process and deselect it before installing. Unfortunately, Apple shipped X11 in Leopard as a work in progress and with many painful bugs. But, as clearly stated by Apple's "Jordan K. Hubbard" at the "X11-users" list:

...X.org is the keeper and primary owner of these bits, not Apple.....Apple does not own or exert significant control over the X.org bits and I doubt that anyone would wish to change that fact....Apple bundles X11, Apple contributes what engineering resources it can to the X.org project, that's the long and short of it...

The good thing is that it's based on a much more modern codebase, and once the bugs are ironed out, I'm confident that X11 in Leopard will be great to use (porting will become easier, we will see a more "Mac-like" behaviour, a better window manager, and a more up-to-date code base).

Ben Byer (CoreOS / BSD Technology Group, XDarwin maintainer) is the main Apple developer working to resolve all the issues with X11 in Leopard. In the past weeks, he started posting at the XDarwin Wiki non official binary and source releases of Xquartz with fixes to issues that have been discovered in X11.app since it was released.

Thanks to his work and the involvement of the X11 community, X11 is already becoming usable again. With the latest release of the Xquartz binaries via open source, now you can use the X server to get some real work done. I want to thank Ben Byer and his group for solving so many different issues in X11 so quickly. A great effort!

The big question is if we will see the updated Xquartz in an official Apple Software Update soon. Apple has answered with the following post by Kevin Van Vechten (BSD Team Manager - Apple Inc.) to the X11-users mailing list:

While I can't comment on future releases, and certainly can't commit to a specific point revision (i.e. the hypothetical 10.5.1), rest assured that we are very interested in delivering Ben's recent work to X11 users via an official channel. Until that time, Ben's work in progress will continue to be available via open source.

I'm sure many people are glad to hear that Apple is interested in enhancing X11 in Leopard via official processes. It feels great that we all want a working X11.

Updated Xquartz binaries

Updated Xquartz binaries are available at the XDarwin Wiki

At the Wiki, you will also find:

Quick Install Script for updated Xquartz and related libraries
Updated libX11 binary. Gimp crash fix
Updated /Applications/Utilities/X11.app binary
Updated xterm. unicode support

For more information about X11 in Leopard:

Some of the issues already fixed in the updated binaries

The middle-mouse emulation is fixed.
The "yellow cursor on Intel" bug was fixed.
The formatting in the .xinitrc warning message was fixed.
PseudoramiX support was enabled by default.
JIS (Japanese) keyboards are now correctly detected by X11.
The "offset-pointer"/"ghost window" bug with Spaces has been resolved correctly.
X11.app supports commands with arguments and respect .Xresources.
Xquartz chews up 100% CPU when running xauth /ssh /xdpyinfo bug fixed.
Fixed bug that caused Gimp (and anything else that uses gtk) to crash.
Customized commands (with args) in X11 Applications menu now work.

Working with launchd

Before Leopard you could control X11 with a series of customizations in your configuration files to make sure everything worked automatically. And now you're shocked because the first time you use a vanilla X11 in Leopard nothing seems to work.

Starting X11.app from the dock will get you two icons, setting it to auto-launch is also a no-no, and if you have set DISPLAY in any of your configuration files you get a disaster.

And, you also realize that they changed the location of the system xinitrc (to match other X.org distributions on other platforms), and they removed xterm from that file. The reason is because in Leopard, the X11.app in /Applications/Utilities is just a little wrapper around the command "/usr/bin/login -fp $USER /usr/X11/bin/xterm". So it's a "launcher" that launches xterm by default. And the starting of xterm then triggers the startup of the real server, which is now located at /usr/X11/X11.app.

Take a deep breath and relax... there's light at the end of the tunnel...

Biggest user-visible change in Leopard X11 is a new launch-on-demand support, courtesy of launchd. If you start a program that tries to open your X $DISPLAY, launchd will check to see if X11.app is running. If not, it will automatically start it for you. So on Leopard, just run a command like xterm or start an application that needs X11, and X11 will start up automatically. This means that now you can just run X apps like you would any other app. But this launch-on-demand functionality only works correctly if X11.app is launched on demand.

So don't run X11.app from the Dock. Or, at all, manually. Ensure that you are not explicitly setting $DISPLAY in any configuration files as it will throw away the location of the launchd socket that X clients need to know how to use, verify that 'echo $DISPLAY' in Terminal.app reports something that starts with '/tmp/launchd', and then just run 'xterm &' from Terminal. This will work with any X11 client application that links with the standard libX11.dylib.

In a few words, you no longer start /Applications/Utilities/X11.app at login or launch the X11.app. You make sure the DISPLAY environment variable is NOT set, and then you simply issue the command, or click on the icon, or whatever, and the rest happens automatically.

Working without launchd

If you don't like launchd you can do the following:

Run /usr/X11/X11.app instead of /Applications/Utilities/X11.app. That will give you a simple, normal X server. You might even move the former to the latter.

The next two steps are optional:

Add an xterm back to /usr/X11/lib/X11/xinit/xinitrc or add it to ~/.xinitrc
That will give you an xterm when you open /usr/X11/X11.app.

To prevent launchd from setting $DISPLAY run:

sudo launchctl unload -w /System/Library/LaunchAgents/org.x.X11.plist

To bring back Tiger's X11

So you decided to wait to install X11 in Leopard until most bugs are fixed and Apple releases an official update. Meantime, you could work with Tiger's X11 in Leopard.

Please read, Aaron Iba's:

Bring Back Tiger's X11 to Leopard in 3 Steps

or Ben Byer's :

Easier instructions to install Tiger's X11.app

You can download Tiger's X11 Update 2006 from here

ssh tunnelling

Assuming you have not set DISPLAY anywhere, you should be able to connect using SSH tunnelling without any special steps:

1.Open Terminal.app
2.run "echo $DISPLAY" -- verify the result is of the form "/tmp/ launchd-xxxxx/:0"
3.run "ssh -Y user@host"
4.after you log in, X11.app should start on your Mac
5.run "echo $DISPLAY"(on the remote host)-verify result is of the form localhost:10
6.run xterm & (on the remote host)-xterm should appear on your Mac

"ssh -Y" works well between Macs running Leopard or Tiger either way, or from a Mac/Leopard to Linux. No difference to Tiger, except that you don't need to set DISPLAY (your DISPLAY will automatically be set on the remote host) or start X11.app.

Note that some people have seen problems with step 4, where X11.app can hang while launching.

ssh X forwarding debugging

Try these SSH troubleshooting steps. This list shows the expected behavior of the system.

local $ -----> refers to commands run on my local Mac running Leopard.
remote $ --> refers to commands run on a remote Unix machine, of any type.

Step 1 - Run:

local $ echo $DISPLAY
/tmp/launch-Bh0fLm/:0

If step 1 returns ':0', 'localhost:0' or anything similar, you have a configuration file that is overriding the system's DISPLAY variable.

Step 2 - Run:

local $ grep DISPLAY ~/.*rc ~/.login ~/.*profile ~/.MacOSX/ environment.plist 2>/dev/null

If step 2 outputs anything, it indicates that a configuration file in your home directory may be the culprit; try creating a new user and repeating the steps with that user.

Step 3 - Run:

local $ grep -r DISPLAY /opt/local/etc /sw/etc /etc 2>/dev/null

If step 3 outputs anything, it indicates that a system-wide change was made that is overriding your environment. If it begins with /opt/ local, it is MacPorts; if it begins with /sw, it is Fink. Otherwise, it is probably a commercial program that uses X11; contact your vendor for an updated version.

Step 4 - Run:

local $ ssh -Y remote
Warning: No xauth data; using fake authentication data for X11 forwarding.

The warning message in step 4 is harmless.

Step 5 - Run:

remote $ echo $DISPLAY
localhost:10.0

If step 5 does not output anything, then step 6 will say "X11Forwarding no". In this case, you must fix the configuration on the remote side.

Step 6 - Run:

remote $ grep X11 /etc/ssh/sshd_config ~/.ssh/*
X11Forwarding yes
X11DisplayOffset 10

If step 6 outputs anything other than "localhost:xx.0", then your remote configuration is overriding the DISPLAY variable set by sshd on the remote side.

Tips and workarounds

You found a bug in X11
Send your bug reports to Apple

A brief history of Apple's X11.app
A brief history of Apple's X11.app by Ben Byer.

8-bit color mode doesn't work.
Workaround: use Xephyr

Fullscreen mode doesn't work.
Workaround: use Xephyr

XDMCP doesn't work.
Workaround: use Xephyr

Launching X11 from the Dock causes strange behavior.
Workaround: Don't do that, then

To open an xterm without starting X11.app first:
a. Open a Terminal.app window and type "xterm" at the command prompt or
b. Open /usr/X11/bin in the Finder and double-click on the xterm icon.

To run another window manager:
Replace the call to quartz-wm in /usr/X11/lib/X11/xinit/xinitrc to change this for all users, or set up a custom ~/.xinitrc.

To get rid of the inital xterm run:
defaults write org.x.X11_launcher app_to_run /usr/X11/bin/xlsclients

Here you can find binaries of Xnest, Xvfb and Xephyr.

Fink initial support for 10.5:
To update Fink to 10.5 just follow the instructions at their Homepage.

To fake fullscreen support with Xephyr:

$ Xephyr -ac -fullscreen :9 &
$ DISPLAY=:9 twm&
$ DISPLAY=:9 xterm &

Hit F8, drag to a different Space, and you've got a fullscreen X server on one of your Spaces.

Leopard and X11