On Nov 29, 2007, at 11:48 PM, Jeremy Huddleston wrote:
This is my current understanding of everything which has been formed over the past month of cleanup and small fixes. I'm sure Ben can refine/fix my comments.
The bulk of our code is on three main locations: GL/apple, miext/ rootless, and hw/darwin. You can think of miext/rootless as the portion of hw/darwin that is cross-platform for rootless servers. Realistically this just means us, but it's there for the bitrotting Xwin.
Yup.
GL/apple contains the code that essentially provides glx. I don't know how this works, and it's not working at all in the master branch.
GL/, in general, contains the server-side portion of the implementation of GLX. My understanding here gets a little fuzzy, too, but the reason we need a copy of Mesa3D handy when we build the server is that it copies a bunch of it into this directory, and when the server gets a "GLX packet", it passes it to the code there. The code in GL/apple is mostly just one file -- indirect.c. This file takes incoming GLX calls and converts them into Core OpenGL (http://en.wikipedia.org/wiki/Core_OpenGL ) calls that the server then executes to draw polygons on the screen. In other words, this is the Xquartz support for Accelerated Indirect GLX (http://en.wikipedia.org/wiki/AIGLX). Rewriting that code was one of the more difficult things I did this year; I copied an early (yet theoretically working) version of that file into the master branch at some point, just in case someone wanted to try to get it working on the master branch. It didn't compile then, and I haven't gotten around to fixing that; there have also been some bugfixes in the xorg-server-1.2 version since I did that copy, so when we get this working in master we may very well want to just delete the one that's there and copy our current one and work from there.
hw/darwin/launcher is /A/U/X11.app... it's independent of anything else and just launches xterm.
Yes. I'd almost rather just start calling it Xterm.app; as has been noted, that's all it is. It's one of those things that seemed like a good idea at the time.
hw/darwin/apple is /u/X/X11.app. It is self contained by by its launch process loads Xquartz.
My understanding of the way that OS X / LaunchServices works is that we have to have an .app bundle in order to have a Dock icon -- among other things, that's how it finds the correct icon to display (by looking inside the bundle). So, /u/X/X11.app is built by Xcode from a bunch of resource files and one actual code file -- bundle-main.c. That code doesn't do a whole lot -- mainly some bookkeeping things. It could probably do a lot more, if we want to keep it. We don't have to. XDarwin did things completely differently: it built two targets, "XDarwin" and "XDarwinApp". XDarwin was roughly analogous to Xquartz, in that it was a standalone binary that you can run to produce an X server. OTOH, XDarwinApp got renamed into XDarwin.app/Contents/MacOS/XDarwin. So, the big difference here is that Apple's version used a small program inside of an app bundle which then called something resembling a normal Unix-y program called Xquartz, while XDarwin put all of the code into the .app bundle. At first, when I got the X.org codebase running, it was as XDarwinApp. I only changed it to X11.app / Xquartz because that's the way it was before; I don't know what advantage one approach has over the other.
hw/darwin/quartz/*.[cm] and hw/darwin/*.[cm] should probably be merged together at some point (refactoring for 1.4 or 1.5 perhaps). They're separated for legacy reasons with the original XDarwin and XDarwin.app codebase that we built off of and have since purged.
Just a bit more to add here: Inside hw/darwin/quartz, there are three subdirectories: fullscreen, cr, and xpr. In the beginning, the X server was fullscreen using direct IOKit calls to talk to the hardware. Eventually, it was rewritten to use Quartz. Next, the first rootless server was developed -- the Cocoa Rootless server. This created Cocoa windows for each X11 window, etc etc etc. XDarwin.app built both of these pieces as bundles -- when you ran it, it would ask you if you wanted to load the fullscreen bundle or the cr bundle. (You had to restart the server in order to switch between modes.) Apple released an X11 Beta for Jaguar, which I believe came with the new libXplugin. (I'm probably wrong, here -- I was still teething at that point.) libXplugin allowed for a greatly accelerated X11 server. libXplugin was then installed as part of the base system -- not X11User.pkg, but the real honest base system -- beginning with Panther. Code was then written to allow XDarwin to use libXplugin -- this was the XPlugin Rootless implementation (xpr.bundle). You could then choose between fullscreen.bundle, cr.bundle and xpr.bundle upon startup. This all left me horribly confused when I got my hands on this code. I don't think selecting fullscreen.bundle actually produced a working display at any point and I'm not sure I bothered much with cr. I ended up linking the xpr.bundle code directly into the server. As far as I know, the only need for quartz/cr is to support machines which do not have libXplugin installed ...
Now, for the launch process... this is ugly... and I am not sure I understand it entirely...
/u/X/X11.app starts (via launchd or whatever)*. X11.app does a fork/ execv to launch Xquartz as a child process (like xinit I believe... but I haven't looked at xinit source to compare exactly). Xquartz's main() is from dix/main.c. This is the ugly part that calls DarwinHandleGUI() in quartz/quartzStartup.c This whole startup process is using Carbon, is broken (we shouldn't be introducing Xquartz specific stuff into dix/* as that breaks Xephyr, Xnest, etc when built together), and is really hackishly ugly. See Ben's post from yesterday about this.
*: I believe the "duplicate dock icon" when launcing it directly is caused by this weird launch process. The bouncing icon belonging to /u/X/X11.app/C/M/X11 and the "usable" one belonging to /u/X/bin/ Xquartz. The bouncing one doesn't show up when launchd starts it because it's not user initiated... this is ENTIRELY speculation though. Ben, have you been able to sit down with the Dock guys about this?
This may very well be -- and I should probably sit down and talk with them about all of this, yes. I haven't yet, and I imagine they're fairly busy dealing with other issues. Unfortunately, I do not have any access to the Dock source. :( -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer