[Xquartz-dev] Re: A map of X11

[Ben Byer]

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