[Xquartz-dev] Re: A map of X11
bbyer at apple.com
Fri Nov 30 07:01:32 PST 2007
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
> 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
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
> 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
> 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
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
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. :(
CoreOS / BSD Technology Group, XDarwin maintainer
More information about the Xquartz-dev