XonX

Hi,

I have been hacking XFree to enable running X windows right beside Aqua windows, without the need to switch between a MacOS X and a X Windows mode. The whole thing is far from being finished, there are still a lot of bugs and quirks, but it is a good start to work on. If anyone wants to test (or improve :-) it:

The source code patch is at http://www.mit.edu/~rueckert/aqua.patch . Check out the latest XFree version from the xfree.org cvs server, copy the patch into the xc directory and apply it with "patch -p1 <aqua.patch".

There are two screenshots at http://www.mit.edu/~rueckert/XFreeAqua.jpg and http://www.mit.edu/~rueckert/XFreeAqua2.jpg .

A binary of the X Server is at http://www.mit.edu/~rueckert/Xdarwin.gz . Install it in /usr/X11R6/bin.

To enable the new "X within X" feature, use the -aqua option instead of -quartz when starting the X Server (either you change the Xmaster source code or you use a .xserverrc file).

Ulrich

Very interesting. I have a clunky rootless mode implemented in Cocoa instead of Carbon. We're moving toward Cocoa-only for event processing because the keycode translation is easier and we can see three hardware mouse buttons. I'm guessing that Carbon Window Manager calls won't work well with Cocoa event handling.

How fast is this? It looks like you're copying the entire X window's contents every time it needs to be updated. It's possible to patch into the X drawing routines to keep track of the changed regions. This (mostly) works in my Cocoa code, and it helps the speed significantly.

I'll look at this some more and try it out this week. Hopefully we'll be able to compare notes and create a good rootless solution.

But in Cocoa do you have to have the Aqua window titlebar as well? I don't really know. I suspect Apple probably implemented a way of creating non-standard-shaped windows in Cocoa. Just a thought...

Yes, you can create something like the famous plaindbox in Cocoa:

[[NSWindow alloc] initWithContentRect:rect styleMask:NSBorderlessWindowMask backing:NSBackingStoreBuffered defer:YES];

Maybe it's possible to create odd-shaped windows in Cocoa, too. I haven't tried that.

Just wanted to mention that I finally got it to work on Mac OS X Public Beta. Xmaster didn't seem to work until I added a .xserverrc file in ~root containing the line "X -aqua" (I already pointed the symlink). Thanks for the binary, Ulrich!

Comments? The xterm windows are a bit slow when typing, but they work. Window dragging is a bit difficult because no window outline appears. I haven't tried other window managers that support solid window dragging. (yes, I'm using twm :). Also, there's no way to bring up X's windows forward in front of any other Aqua window, so I have minimize or hide everything else to see what I'm typing.

Don't use twm :-) twm supports solid drag (add a line "OpaqueMove" to a .twmrc file), but window placement and resize are still blind. There's no good way to fix this; twm draws directly to the desktop, but Xdarwin can't allow that safely.

To bring windows to the front, you need click-to-raise behavior. twm doesn't do that, as far as I know.

If XonX already works by copying window contents, why not solve the problem more generally based on an existing platform?

The VNC project (at http://www.uk.research.att.com/vnc/) already has standalone X/VNC servers and instrumented drawing code. Currently, VNC works on a per-screen basis, but making it work for separate windows should not be all that hard.

The work of adding a windowed feature to VNC would probably be less than the work of getting the current XonX to a fully released state. In VNC, all of the instrumentation has already been done, there are already established change and communications protocols, and there are clients for MacOS.

Furthermore, addressing this problem in general would benefit a lot of people in addition to the MacOS community (which also means that there are more potential contributors to the project).

Of course, this may or may not be the long term direction you want to take XonX into. But I hope you'll consider it.

The bottleneck here is the VNC protocol itself. The VNC protocol knows nothing about windowing or layering or anything other than a single fixed rectangle with pixels in it. The protocol would need significant extension to handle those issues. Additionally, Xvnc's instrumentation is insufficient and all current clients would be incompatible; the work needed to fix them is approximately the same as the work needed to implement real rootless X.

This is great, but it didn't work for me. Can someone give step by step directions on how to get it to work. I tried using the binariy. I overwrote the old binary and then created the.xserverrc file with "X -aqua". Now Xmaster tries to load it, moves the cursor to the center of the screen and then crashes when the mouse is moved. No actual things besides the welcome window get displayed on the screen. What am I doing wrong? Or can someone offer step by step direction?

Thanks,
Dave

I've noticed on the XFree-devel list that the Cygwin people are doing an implementation that routes all 2D primitives to GDI, thus allowing to take full advantage of the GDI hw. acceleration. I guess that would be the best long-term route to have something that works both rootless, and with good performances.

Heh... I'm the Cygwin "folks" that are trying to implement a GDI based X server. However, I'm getting hung up on color formats and Device Context allocation, etc., so I figure it would be a good idea to do a quick and dirty shadow fb based server to answer some of my questions.

Does xonx use shadow fb?

I'm not using shadowfb itself, but a large chunk of code works the same way as shadowfb: wrap drawing operations to record changed areas. I didn't know about shadowfb when I started; it should be possible with a little work to convert it to shadowfb instead.

After further investigation, I rediscovered yet again why I'm still not using shadowfb: it assumes there's one pixmap for the whole screen, which is not true for us. The rootlessfb used by Xdarwin cannot use the current shadowfb.

regions in rootless X11 can be avoided entirely by creating a new CoreGraphics surface for every drawing port. This would also be a lot faster than XTools which copies an offscreen video buffer (in RAM). It would also be more compatible.

Interesting...

For Cygwin/XFree86 I'm thinking about just writing a window manager... that would get about the same effect as the rootless XonX, but it would probably be easier :)

In any case, writing a window manager seems to be the track taken by the majority of commerical X on Windows packages.

Have you guys considered writing a window manager instead of the current slight of hand method of gettind X to be rootless?

Harold

I don't know much about what window managers can and cannot do, but it seems that writing just a wm wouldn't be that great. Is the wm notified when a window's contents change? You need that to copy from the 'framebuffer' into the rootless windows. Also, on Mac OS X, all windows are double-buffered by the OS. This makes window drag very fast, unless X is taking the time to unnecessarily shuffle pixels around.

The 'sleight of hand' method is working very well now. It should be possible to use it in conjunction with a OS-aware wm, or on its own as I'm doing now.

Hi i've been reading alot about region copying and window manager implementation, and it seems like you want to remove that, and just have it draw directly to Quartz's buffer, as an aside, why can't we make an Aqua Window manager, so picky ppl that want it can use IT instead of lovely Enlightement...mmm....ok enough of that. I've been thinking of a reimplementation of Gtk as well. i'll be hacking away at all of this, and report back when i have anything worth looking at... O and i'll look at the patches too while i'm at it. I'm dissapointed that thats all there is... i couldn't find the source to Xmaster.... is that just a patch too?

Does this work with the released version of MacOSX? I downloaded the binary Xdarwin, and I've tried on a Lombard and a Pismo laptop and it didn't work with either.

It does start up using -quartz, although the keyboard doesn't work.

[localhost:~] hcaley% startx

Faking a three button mouse
Aqua activated.

XFree86 Version 4.0.2 / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: 18 December 2000
If the server is older than 6-12 months, or if your hardware is
newer than the above date, look for a newer version before
reporting problems. (See http://www.XFree86.Org/FAQ)
Operating System: Darwin
Mac OS X Quartz support available.
Mac OS X Aqua support available.
GlueOsVendorInit started!
GlueOsVendorInit finished!
AquaDisplayInit started!
AquaDisplayInit finished!
AquaAddScreen started!
AquaAddScreen finished!
AquaCreateWindow!
*** malloc[346]: error for object 0x8492c: Incorrect check sum for freed object - object was probably modified after beeing freed; break at szone_error

We can't draw directly to the Quartz buffer because there's no publicly-available API to do it. I would *love* to do it that way - it's faster and probably easier - but there's no Apple-sanctioned way to do it, at least not yet.

An Aqua window manager is possible, but the non-Aqua version is simpler and we have our hands full already.

Xmaster is obsolete. All of the code is part of XDarwin itself now. Ulrich's rootless patches don't work anymore.

Thanks Ulrich. Glad to see people tackling this! I'm having some trouble getting the binary to run (I didn't roll my own original Xdarwin, so I'm not considering patching). The -aqua param chokes unless I give it at least a -size. Here's what I get:

bash-2.04$ ./Xdarwin -aqua -size 1152 870 -depth 24 -refresh 75
Aqua activated.
Attempting to use width x height = 1152 x 870
Attempting to use pixel depth of 24
Attempting to use refresh rate of 75
[...]

Operating System: Darwin
Mac OS X Quartz support available.
Mac OS X Aqua support available.
GlueOsVendorInit started!
GlueOsVendorInit finished!
AquaDisplayInit started!
AquaDisplayInit finished!
AquaAddScreen started!
AquaAddScreen finished!
AquaCreateWindow!

------
And it just hangs there. Am I missing a param? The display details I gave it are what I'm running Aqua at.

j

Ok, thanx for the clearup. I've gotten a few undeclared interfaces to work with CoreGraphics, and i may get more working, but i think it may be better to either try a different aproach -- or reimplement Quartz altogether. Its not as bad as AppKit, it has 12137 private functs, 1832 public and 70 (3.82%) of pub functs declared in the Headers. Quartz, (CoreGraphics) only has 3293 private, 1454 pub, with 240(16.5%) of them being declared in the Headers. now i know this doesn't account for structs, those could be redone, but i think its possible. I'm talking about a binary-compatible (OpenSource) Quartz server. Don't laugh at me right away.....

Andrew Robbins

I think an Aqua wm facade is the worst idea ever. X11 apps do not behave like mac apps, I try to make them look as different as possible!

I'd sure like to know what you had to do to get WindowMaker to compile. I got stuck right at the libPropList configure.

Thanks,
Paul

After months of banging my head against Cocoa and Carbon events and window manipulation, I've finally fixed enough problems and released my rootless code. Directions, warnings, a patch and a link to a binary are in the SourceForge patch tracker.

Check out XTeddy, the MacOS X version. Although simply showing a window with a picture, and shape, of a bear it shows what's possible.