May 2008 - Xquartz-dev - lists.macosforge.org

2.3.0-rc3
by Jeremy Huddleston 04 Jun '08

04 Jun '08

I've uploaded a new release candidate for 2.3.0. I've been using this for about a week now and feel comfortable enough about it to put it out "in the wild" to let you all mess with it while I move on to the next stage of the startup rewrite. Major changes since 2.3.0-rc2: Pulled in proper xkeyboard-config data instead of xkbdata (this should get Xfake and Xephyr to work without needing the '-kb' command line option) Reverted Xquartz to not use xkb since we don't actually have a quartz keyboard xkb data file (not sure the best way to solve this, I'm going to leave this headache for post-2.3.0) Xquartz now has the capability to add a new $DISPLAY socket after the server is started (rather than only at start). This is needed for the new OSX-friendly startup method that I'm working on. We use this now just within the server itself, but in rc4, I expect the socket will be handed off to the server by the stub. Please test it out and let me know of any regressions. http://xquartz.macosforge.org/downloads/X11-2.3.0_rc3.pkg Note, I consider this fairly stable and regression free at this point, but there are bound to be some issues that arise. Now that I have this out, I'm going to be working on some things that are a bit more fragile, so if you want to balance "works" with "testing", this should be a fairly safe beta for you. Of course, I may end up eating these words later... --Jeremy

8 19

Stereo (graphics) support survey
by Ben Byer 30 May '08

30 May '08

I'm working on getting (stereo) 3-D support working in Xquartz, and it'd be helpful to know what kinds of equipment people out there are trying to get working. If you have a working 3-D setup on OS X (but not necessarily with X11.app), please email me off-list and tell me: * What graphics card you are using * What stereo hardware (Glasses? Emitter? etc) you are using * What non-X11 software you are currently running in Stereo mode on OS X * What X11 software you are trying to get working in Stereo mode on OS X -b

2 1

2.3.0-rc1
by Jeremy Huddleston 29 May '08

29 May '08

I've just finished uploading the first release candidate for the next X11 package installer. You can find it here: http://xquartz.macosforge.org/downloads/X11-2.3.0_rc1.pkg Some notes (IMPORTANT, READ ME!!!): The installer requires 10.5.3, so if you don't have access to a seed of 10.5.3, you'll have to wait until release. This package doesn't "really" need 10.5.3, but I don't want people to install the 10.5.3 OS update after this package and then forget to reinstall X11 because it will cause some issues due to the new startup mechanism (you'll loose the X11 menus, etc). As of 2.3.0-rc1, the server bits are actually located in the bundle. / usr/X11/bin/Xquartz is just a stub that "does the right thing" to start the server (for now, it's just doing an exec(), but it will be done via Mach-IPC in the future). This allowed us to clean out all the extra cruft we had in xinit. There are some side-effects to note: If you copied or moved your X11.app bundle from its default location, you will need to update the copy with the new one after installation. If you don't, you run the risk that /usr/X11/bin/Xquartz will find the old one and you'll see messages to Console.app indicating this. If X11 fails to start after updating to 2.3.0, this is the most likely culprit. Check Console.app for debugging messages that will tell you the location of X11.app that Xquartz is finding. You will not be able to use any of the Xquartz binaries from previous releases with this release, and visa-versa. That is why I haven't made an updated binary drop for a while. From now on, you'll need to grab X11-1.4.0-appleXX.bz2 and drop it over /Applications/Utilities/ X11.app/Contents/MacOS/X11 rather than updating /usr/X11/bin/Xquartz. ChangeLog: http://xquartz.macosforge.org/trac/wiki/ChangeLog

5 16

1.4.0-apple6
by Wes Turner 20 May '08

20 May '08

My apologies if this is the wrong place to post this message, but it seems like a good place to start. I had the XQuartz hanging problem (_xp_async_dequeue lockup) mentioned in the post and can confirm that 2.2.1 appears to fix the problem. Is there any indication of when this will be picked up in the Apple Leopard update cycle? Thanks in advance, - Wes -- Wesley D. Turner, Ph.D. Kitware, Inc. R&D Engineer 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-371-3971 x120

2 2

XKB in XQuartz
by Jeremy Huddleston 19 May '08

19 May '08

I'm having a bit of trouble now with the "use XKB" conditional #ifdef in the XQuartz keymap handling (I reverted back to the old way for now). It was "working" before simply because xkeyboard-config wasn't installed (I installed xkbdata, it errored, and we kept our default mappings). Now that I install xkeyboard-config, we get an ugly mapping. Here's our modifier keys for example: xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift backslash (0x32), BadKey (0x3e) lock Alt_L (0x42) control 0 (0x25), F9 (0x6d) mod1 Alt_L (0x42), Alt_R (0x45) mod2 KP_Add (0x4d) mod3 mod4 End (0x7f), F2 (0x80) mod5 KP_3 (0x5d), Prior (0x7c) And if I revert back to the old way or just move the share/X11/xkb directory out of the way (which causes the fallback to the old way), I get a good mapping: xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x40), Shift_R (0x44) lock Caps_Lock (0x41) control Control_L (0x43), Control_R (0x46) mod1 Alt_L (0x42), Alt_R (0x45) mod2 Meta_L (0x3f), Meta_R (0x47) mod3 mod4 mod5 So I dug around a bit and figured this was resulting from this line picking an invalid rule set for our keyboard: XkbSetRulesDflts("base", "pc105", "us", NULL, NULL); Now, how should we go about creating rules for our keyboards? I've done some keyboard config writing for the Sun Type 6 USB keyboard, so I'm a little familiar with that, but in that case I had a "real" keyboard to work with and I didn't need to worry about international variants, etc. I'm a bit fuzzy on exactly how the keyboard data is provided to us by Quartz and how to make that play nice with xkb. For one thing, QuartzReadSystemKeymap() (the old way) gets the keymapping data (keycode -> unicode character) dynamically from the system. From what I see, xkb gets its data from the config files... it seems like a bad idea to try generating files in xkeyboard-config for all the possible keyboards that can be available. Is there a way we can still use xkb but not rely on xkeyboard-config? Should we just setup a very basic generic profile (maybe just the modifier keys) for the quartz keyboard and programatically setup the rest of the bindings? Daniel, is there a better option that you can think of? Thanks, Jeremy

1 0

New X11 icon
by Simone Karin Lehmann 18 May '08

18 May '08

It was quite a while ago that I was bored with X11.app's b&w icon. And since X.org has a, IMO, more pleasing and colorful logo I created a new icon. It's based on this logo and the SVG I've found under http://commons.wikimedia.org/wiki/Image:X.Org_Logo.svg . So here's a preview http://www.lisanet.de/pivot/entry.php?id=41 and the download (right click on it) http://www.lisanet.de/images/X11.icns What do you think about putting this into the X11.app bundle? Simone -- in the arms of your angel, you may find some comfort here.

3 3

1.4.0-apple8: monitor hotplugging
by Jeremy Huddleston 06 May '08

06 May '08

I think I finally have a solution for monitor hotplugging. Please try out 1.4.0-apple8 if you're interested in multi-monitor support and specifically monitor hotplugging. http://xquartz.macosforge.org/downloads/Xquartz-1.4.0-apple8.bz2 Thanks, Jeremy

2 3

2.2.1 Released
by Jeremy Huddleston 05 May '08

05 May '08

I'm happy to announce a new release of X11 available for OS-X. The 2.2.1 release brings many stability fixes to the server. All known crashes have been fixed in this release! There are also a couple non-crash bug fixes in here as well: Cmd-tab now works as expected. Closing an X11 window will no longer move you to a different space. XBell() now works as expected. This version also pulls in newer versions of pixman and cairo and includes the xkb utilities. Full release notes are available here: http://trac.macosforge.org/projects/xquartz/wiki/X112.2.1 The next release will probably be based off the 1.4 server branch and hopefully released in the next couple weeks. If you're interested in trying it out, I'll be continuing to announce release candidates on xquartz-dev. For those of you who installed 2.2.1-rc2, the 2.2.1 final is identical to 2.2.1-rc2. Thanks, Jeremy

2 4

Exposé bug again
by Harald Hanche-Olsen 04 May '08

04 May '08

I thought the exposé bug had been fixed quite some while ago? Well I am seeing it again. Is it a regression, or what? I am talking about ticket #78 http://trac.macosforge.org/projects/xquartz/ticket/78 which is closed, with resolution: duplicate. Here I must digress and report a bug in the bug tracking system: It doesn't tell you what bug report it is a duplicate of! It should not be possible to close a bug with resolution: duplicate without specifying this vital information, and without that information being visible afterwards. However, I am unable to find it after quite a bit of looking. Anyway, ticket #78 describes exactly what I am seeing, so I won't repeat it here. Xquartz-1.4.0-apple7, X11 2.2.1-rc2 (said to be identical to 2.2.1, so I haven't upgraded), and Ben's quartz-wm. - Harald

3 3

Resizing the root window
by Jeremy Huddleston 04 May '08

04 May '08

I'm trying to figure out some issues with monitor hotplugging in Xquartz, and I think I've narrowed it down to the way we try to resize the root window and I was hoping to get some feedback on what would be "the right way" do do this. We try changing the dimensions of the root window via: pRoot = WindowTable[pScreen->myNum]; pScreen->ResizeWindow(pRoot, x - sx, y - sy, width, height, NULL); I've spewed out some debugging that shows the following: Calling: RootlessResizeWindow(pRoot, 0, 0, 1440, 1860, NULL) pRoot->drawable now: 2720, 960 pRoot->clipList.extents now: 2720, 960 pRoot->borderClip.extents now: 2720, 960 pRoot->winSize.extents now: 2720, 960 pRoot->borderSize.extents now: 2720, 960 pScreen->ResizeWindow is RootlessResizeWindow which essentially just does miSlideAndSizeWindow via: HUGE_ROOT(pWin); SCREEN_UNWRAP(pScreen, ResizeWindow); pScreen->ResizeWindow(pWin, x, y, w, h, pSib); SCREEN_WRAP(pScreen, ResizeWindow); NORMAL_ROOT(pWin); Breakpoint 1, RootlessResizeWindow (pWin=0x581370, x=0, y=0, w=1440, h=1860, pSib=0x0) at rootlessWindow.c:1369 (gdb) print pScreen->ResizeWindow $1 = (ResizeWindowProcPtr) 0x4f85f <miSlideAndSizeWindow> And in miSlideAndSizeWindow, we have: /* if this is a root window, can't be resized */ if (!(pParent = pWin->parent)) return ; So it looks like this is intentional. So... how should I be resizing the root window? Thanks in advance, Jeremy

1 0