Re: A map of X11
Re: A map of X11
- Subject: Re: A map of X11
- From: Ben Byer <email@hidden>
- Date: Fri, 30 Nov 2007 07:01:32 -0800
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden