November 2007 - Xquartz-dev - lists.macosforge.org

Expose restacking
by Nathaniel Gray 02 Dec '07

02 Dec '07

I just ran the following test after instrumenting the kXDarwinWindowState event (quartz.c, line 460ish): Starting from Terminal.app without X11 running: $ xterm & $ xterm & Then I used Expose to restack the xterms. Note that focus never went to X11.app $ killall X11 Then I tried again, but this time I didn't do anything with Expose: $ xterm & $ xterm & $ killall X11 The log output was identical for both tests. So we're not getting that event on Expose window restacking. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

2 1

X11 Tiger xmodmap
by Jeremy Huddleston 01 Dec '07

01 Dec '07

Hey Ben, Since do you have any machines with Tiger's X11 on it? Can you give me the output of 'xmodmap'? I just want to make sure that we maintain consistency with Tiger's X11 in our stance on the Alt versus Mode_switch default decision. --Jeremy

2 4

odd hang with NDEBUG
by Jeremy Huddleston 01 Dec '07

01 Dec '07

So I cleaned up the source files to all include xorg-config.h ... but when I did that, I got a weird hang. I narrowed it down to NDEBUG being defined for assert.h. Undefining it for that include causes the problem to go away. I don't know why, and I can't seem to replicate it in a small test case like this: #define NDEBUG #include <assert.h> int main() { assert(0); return 1; } Anyways... I committed this to 1.2 and will do the same for 1.4 tomorrow. --Jeremy

2 3

X11Application.m
by Jeremy Huddleston 30 Nov '07

30 Nov '07

Oh, there was one other difference in X11Application.m that I wasn't sure of... what's going on here? @@ -309,9 +309,6 @@ static void message_kit_thread (SEL selector, NSObject *arg) { } - (void) set_front_process:unused { - [NSApp activateIgnoringOtherApps:YES]; - - if ([self modalWindow] == nil) [self activateX:YES]; QuartzMessageServerThread(kXDarwinBringAllToFront, 0); }

2 1

Re: A map of X11
by Ben Byer 30 Nov '07

30 Nov '07

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

1 0

dist-2.1-alpha1
by Jeremy Huddleston 29 Nov '07

29 Nov '07

(CCing you directly since I haven't tested the list yet) I've put up a tarball of what I think should be in our first .pkg release here http://people.freedesktop.org/~jeremyhu/dist-2.1-alpha1.tar.bz2 . I'm assuming we should just call it 2.1 and have the X11.app About menu reflect this. I've included the newer damage/randr protos, your compiled xterm, my compiled libX11, my compiled xfs, my compiled Xnest/Xephyr/Xfake/Xvfb, my compiled /A/U/X11.app/C/M/X11, as well as some fixes to fontconfig and xfs config files to include /Library/Fonts and /System/Library/ Fonts in their searchpaths. We will need to do these as the superuser on install: mkfontdir /Library/Fonts mkfontscale /Library/Fonts mkfontdir /System/Library/Fonts mkfontscale /System/Library/Fonts I believe this should solve the issue the user was complaining about OS-X fonts not being available in X11. The only difference between whats in the tarball and what we release should be the Xquartz binary... assuming we don't find out about other broken libs or apps between now and next week... I have no experience dealing with .pkg creation, so I leave that ball in your court. --Jeremy

1 0