X11 on Leopard is broken

2007-10-29 12:55:25 UTC

See also the follow-up: How to make X11 work better on Leopard.

In Leopard, Apple switched from XFree86 to X.org for its X11 implementation. This caused a few things to break.

Some of these are legitimate brokenness; some of these are just changes that break people’s expectations. I’ll attempt to list them all here.

.xinitrc is ignored (sort of)

In Tiger, when you launch X11, it runs .xinitrc, and .xinitrc runs xterm (unless you comment that line out).

In Leopard, X11.app is just a launcher. All it does is run /usr/bin/login -pf $USER /usr/X11/bin/xterm. In other words, its only purpose is to run xterm (semi-)directly, by itself—it’s not the actual X11 server anymore. When xterm starts, launchd sees it, notices that xterm requires X11, and launches the real X11 server (/usr/X11/X11.app) automatically. The X11 server then runs .xinitrc—but by this time, xterm is already running, so no changes in the .xinitrc can affect it.

This may be just an architectural change: You can’t rely on .xinitrc having been run by the time xterm is running. If not, it’s a bug: .xinitrc is supposed to have completed before any processes that use X11 begin running. I don’t know enough about X11 to know which is the correct behavior.

xterm ignores .Xdefaults when invoked by login

As mentioned above, the X11 launcher does its magic by invoking xterm through login. Unfortunately, when xterm is invoked as a login process (argv[0] starts with '-'), it ignores the contents of your .Xdefaults file—no custom fonts, no custom geometry, nothing; just a stock 80×24 black-on-white terminal.

I’ve created a different launcher that doesn’t go through login in order to work around the problem. I call it xterm.app. Since it doesn’t use login, xterm isn’t invoked as a login process, so it uses .Xdefaults, as it should.

Two X11s

X11’s new two-factor design is similar to the design of the mouse-based app launcher Sapiens. Like Sapiens, X11 now consists of a front-end launcher app and a hidden back-end application.

As with Sapiens, this gets confusing if you put the front-end launcher in your Dock, because when you click that tile, two things happen:

  1. That application exits immediately after you start xterm. Its little white LED comes on for just a fraction of a second.
  2. When xterm starts, launchd starts the back-end app to support it. The back-end app isn’t an LSUIElement, so it gets its own Dock icon.

The idea is that you should be able to simply launch an app that requires X11, and X11 will start automatically. If you use xterm as your terminal, and don’t use any other X apps (for which purpose you always had to launch X11.app directly), the best replacement (currently) is my app.

Option-click is broken

Laptops don’t have a middle mouse button, which you need if you want to paste into an X11 window. Thus, those of us with laptops have traditionally used X11’s “Emulate three-button mouse” feature, which maps option-click to middle-click and ⌘-click to right-click.

Unfortunately, this is broken in Leopard. Option-click does nothing; in xterm, ⌘-clicking on the scroll bar is acting like middle-clicking should, and ⌘-clicking on the terminal text area itself seems to do nothing but clear it.

It still looks like Tiger

quartz-wm draws X11 title bars with the Panther/Tiger appearance, rather than the new, darker Leopard appearance. It also has Tiger-sized rather than Leopard-sized drop shadows.

Windows don’t stop at the menu bar

You can’t move a regular Aqua window up underneath the menubar. But you can do this with an X11 window. It’s possible to become unable to recover the window this way.

Applications menu doesn’t work with arguments

Added at 15:44 PDT.

Apple’s X11 has always had an Applications menu that serves as a quick launcher for X11 programs. In Tiger, this launcher did the right thing with command-line arguments; either it went through the shell (perhaps using system(3)), or it split up the arguments and passed them separately to exec(3).

Leopard’s Applications menu is broken: It takes the entire command line you defined and passes it as one argument to execvp. It doesn’t know of any program by that suspiciously-long name, so the launch fails and you get an error message in the Console log.

Can’t drag a window to another screen

Paul Thomas mentions this in a comment here, but my friend Alan Boyd has more details:

It seems impossible to move an X11 window on to another monitor. The window itself is able to cross the boundary, but the mouse pointer is not. As a result, the entire window cannot be moved across. I’ve tried doing it in two steps, but once the window is placed on the boundary, it is not allowed to travel any further away from the original monitor.

X11 doesn’t activate like it’s supposed to

More from Alan’s post:

When launching X11 the menu bar is not set up correctly. Instead, the menu bar from the application that was active when X11 was launched is shown, rather than X11’s own menu bar. Clicking on the window that opens seems to rectify this problem.

Basically, X11 doesn’t come to the front when you launch the first process that requires it, like it should.

My xterm.app utility works around this bug, too: it runs its activate application "X11" script twice in order to make sure it comes to the front.

I will update this post as I find new bugs, and as I file Radar reports for these.

23 Responses to “X11 on Leopard is broken”

  1. Jason Weathered Says:

    Oh good, I’m not the only one who uses X11.app :)

    I really like the new auto-launching behaviour, but since I can no longer use the Applications menu because of it’s brokenness and the launch proxy dock icon behaviour, I have to replaced them with shell scripts which I launch via Spotlight and removed X11.app from my open at login items.

    Additionally now my previously working Wireshark build from MacPorts is now getting X11 errors:

    The error was ‘BadMatch (invalid parameter attributes)’. (Details: serial 13488 error_code 8 request_code 152 minor_code 4)

    A fresh build after updating MacPorts doesn’t help. Running Wireshark from my Debian server does though so it may actually be a client side bug (i.e. in my Wireshark or GTK/GDK builds). Another one of those things to look into when I get a chance :)

  2. Paul Thomas Says:

    I just noticed that I can’t drag any X11 windows to my second monitor (placed to the left of the main one).

  3. Tim Buchheim Says:

    full screen mode seems to be broken too.

  4. Peter Hosey Says:

    Tim Buchheim: How so? Mind being a little more specific? ☺

  5. Art Says:

    Another X11 bug I’ve noticed – you can the title bar of an X window above the OS X menu bar, making the window inaccessible. At least, I can. Regular OS X windows don’t seem to have the problem.

    Also, my emacs windows are now twice as large as they used to be under tiger. None of my other X apps are doing this. This must have to do with some sort of default font size change, but I can’t imagine where it would be …

  6. Art Says:

    Crap, first sentence should be: … you can DRAG the title bar of an X window above the OS X menu bar …

  7. Peter Hosey Says:


    … you can drag the title bar of an X window above the OS X menu bar, making the window inaccessible.

    Yes. That’s already listed in the post.

  8. Art Says:

    Ah, evidently I can’t read. Thx

  9. Adam Durana Says:

    I too ran into the Wireshark bug. There\’s a Wireshark bug logged in their database of bugs, but a work around that appears to work is to set the \’Colors\’ option to \’Thousands\’ in X11.app.

  10. Dave Schroeder Says:

    There is a LOT of discussion about this on Apple’s X11-users list…I’d recommend joining. Many, many problems have already been resolved in unofficial builds released by Apple’s X11 maintainer (who is also an XDarwin maintainer). The X11 maintainer at Apple is actively responding to problems and requests:


  11. Peter Hosey Says:

    Dave Schroeder: I’d seen some of it; I put a couple links to messages in that thread in the post.

    However, I wasn’t aware that, in your words, many problems are fixed already. That’s good news, so thanks for the follow-up.

  12. Jason Weathered Says:

    Adam Durana at 2007-11-01 17:57 UTC wrote:
    > set the ‘Colors’ option to ‘Thousands’ in X11.app.

    Thanks for posting this workaround. Another item off my Leopard teething list.

  13. Rick Robino Says:

    Again, thanks for the tip. Saved me from having to fork up for Etherpeek, if they even have a Leopard version. Anyway…

    Regarding wireshark: in addition to the suggestion to set the colors to thousands (and restart X11 apparently), you may also need to keep unset DYLD_LIBRARY_PATH [so that Apple’s default lib path will be followed] and set DYLD_FALLBACK_LIBRARY_PATH [so that your own library path will be followed]. This works around a behavior that exhibits itself as:

    dyld: Symbol not found: __cg_jpeg_resync_to_restart
    Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
    Expected in: /opt/local/lib/libjpeg.62.dylib

    Another tip: install portaudio before configure runs when building wireshark. wireshark will pick it up and give you the (G711) player even though it might not be an option in automated build systems that handle dependencies like macports.

  14. Bert JW Regeer Says:

    A new version of quartz-wm has been posted by an Apple employee at http://www.x.org/wiki/XDarwin follow the installation instructions, and Wireshark will work again as expected. It also fixes the bug of being able to drag a Window to a second screen.

    There are still some issues with Focus, but it has to do with the way Mac OS X handles Spaces.

  15. Richard French Says:

    I just installed Leopard X11 on my G5, and when I try to enlarge an xterm window by dragging the lower right corner, it kills X11 completely. Has anyone else run into this problem? Suggestions? Would doing a clean install rather than an upgrade from Tiger make any difference?

  16. Stu Says:

    The latest update, 10.5.1, has totally broken X11 for me. I even tried xterm.app, but either way, it just tries to open and dies.

    It either appears twice on the dock, and then disappears, or it appears, shows an xterm window, without a frame around it, and when you click on the window, it dies.

    Anyone else have this problem after updating Leopard?

  17. Kevin Turpie Says:

    I use a lot of X11 apps and I’ve had all the problems mentioned in the post. This is frustrating. I am used to doing a lot of cutting and pasting with my laptop (between editor and command line) and this just doesn’t work anymore. In addition to the various foibles mentioned, I’ve noticed that the scroll bar and other features I’m accustomed to seeing in xterm are missing. It’s probably the side stepping of .Xdefaults, but I don’t know.

  18. Peter Hosey Says:

    Kevin Turpie: I haven’t noticed any scroll-bar problems, but you’re right that it may be .Xdefault-related.

    Anyway, I suggest that you check out the follow-up post that I linked up top, and consider whether it’s worth it to you to try one of the alpha versions that have come out since Leopard.

  19. Orv Says:

    When I run KDE apps in Leopard — either locally, or via X forwarding — scrolling doesn’t work properly. Instead of the new window contents replacing the old, they overwrite the old ones, making an illegible mess. Does anyone know of a workaround?

  20. mk Says:

    I do like the feature that you can simply run ssh -X user@host gnome-session in a normal terminal to get things started, but Leopard has rendered X11 useless. It resizes to a fill my entire screen, except that my gnome top and bottom menus are covered by the Mac’s bar, so I can’t click anything. Firefox seems to run ok in a window…

    Anyone know how to force X11/Xorg to run at say 1024×768 instead of trying (in my case) to make the resolution 1920×1200???

  21. Jason Weathered Says:

    mk: I think you\’re after Xnest. Something like the following should do the trick:

    Xnest -geometry 1024×768 :1& DISPLAY=:1 ssh -X host gnome-session

  22. Jason Weathered Says:

    Hmm, it seems if one forgets to answer the anti-spam question, a not so pleasant dose of addslashes() is applied to the comment text.

    Oh isn’t PHP fun? :)

  23. Neal Says:

    I got around the broken cut/paste problem by installing ETerm (using port), option-click in ETerm pastes the highlighted text.

Leave a Reply

Do not delete the second sentence.