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

2.4.0_beta1
by Jeremy Huddleston 02 Jun '09

02 Jun '09

Hi everyone. I'm proud to announce that 2.4.0_beta1 of XQuartz is ready. With this release, we've jumped to the 1.6 server branch, updated libX11, libxcb, pixman and various others from their rc versions to final release versions, and integrated massive improvements to our GLX support thanks to George's hard work. A list of all changes since 2.3.2.1 can be seen in our ChangeLog: http://xquartz.macosforge.org/trac/wiki/ChangeLog And here's the dmg: http://static.macosforge.org/xquartz/downloads/X11-2.4.0_beta1.dmg For those that are interested, the source code for our libGL is available in svn (see our websvn interface at http://xquartz.macosforge.org/trac/changeset) or from http://xquartz.macosforge.org/downloads/src. The X11 server is seeing massive changes to its input handling to support multiple devices and multitouch. As such, the 1.6 server branch has seen a fair number of changes as a stepping stone toward that end. Unfortunately, all the kinks have not been worked out of input handling, so most of the known regressions are related to input: * capslock doesn't work * a possible race condition can cause xmodmap to ruin your key mappings * workaround: move your ~/.Xmodmap file somewhere else and load it after X has already started * sometimes X may stop responding to your mouse * George has seen this, but I haven't. If someone can help with reproducibility, I'd be grateful George also has some note regarding the GLX improvement (we now support GLX-1.4): AppleSGLX Release Notes o OpenGL Support AppleSGLX supports the same version of OpenGL as Leopard (OpenGL 2.1). Many extensions from the OpenGL framework are now builtin. This adds support for GLSL, and a variety of other features. o Thread Support Thread support has been improved since the libGL in XQuartz 2.3.2.1. o GLX 1.4 Support The GLX 1.3 and 1.4 functions should all work with a few exceptions as outlined in this document. o glXMakeContextCurrent (a GLX 1.3 feature) glXMakeContextCurrent should work with the readable drawable. The OpenGL functions: glReadPixels, glCopyPixels, and glCopyColorTable, should use the readable drawable if it's different than the rendering drawable. o glXGetProcAddress (a GLX 1.4 feature and ARB extension) glXGetProcAddress should work and allow getting the address of any extension functions you may need from the X11 libGL, or OpenGL framework libGL. Previous versions of the X11 libGL didn't allow getting the newer OpenGL framework addresses. o GLXPixmaps New support for GLXPixmaps works well with mixed X11 and OpenGL drawing operations. You can create them using glXCreateGLXPixmap or glXCreatePixmap. o GLXPbuffers Support for GLXPbuffers has been added. These are drawables that are not possible to render to with X11, which is allowed by the spec. A GLXPbuffer will never generate a clobber event, however glXSelectEvent and glXGetSelectedEvent should operate normally. Clobber events are not generated due to low-level architectural differences. The contents of your pbuffers will not be clobbered. o Shared Contexts Due to basic low-level architectural differences the usage of shared contexts requires a similar visual or GLXFBConfig be used in the creation of a shared context. It's best if you specify the same visual. This is due to a CGL design difference, and not something that is easily worked around. o Indirect The X server supports indirect fairly well, so OpenGL applications can be run remotely and displayed by XQuartz. This means you can run applications from a remote host on an XQuartz X server. AppleSGLX does not support indirect rendering. Any indirect context created will appear to glXIsDirect as an indirect context, but it does not actually support indirect rendering to a remote X server. AppleSGLX supports GLXPixmaps and GLXPbuffers with direct and indirect contexts, though they are all direct contexts by definition (see above).

7 13

X11 Translations
by Jeremy Huddleston 29 May '09

29 May '09

Some of you have been asking for updated translations of the X11 preference pane, so you can access the new preferences. Here they are. Please install these locales after 2.3.3.2 (they should work fine on 2.1.6 as well if you want to stay "pure" Apple). These localization updates will be in the next beta release of 2.4.0 as well. http://static.macosforge.org/xquartz/downloads/X11-Locales-2.3.3.2.dmg Thanks, Jeremy

1 0

256 color 2.3.3.2
by xquartz-dev.5.mzs＠spamgourmet.com 21 May '09

21 May '09

Hi, I updated a 1GHz G4 PPC eMac with ATI graphics to 10.5.7 and 2.3.3.2 and decided to try 256 color mode in the X11.app preferences and it did not work. Here is what I did: Fire-up Terminal.app and start X11.app with xlsclients propeller-tab to X11.app In the X11.app menubar select the item that fires-up an xterm The xterm seems to work, but then I type xlogo in the xterm xterm loses focus but I do not see xlogo anywhere More details, xlogo is in the Windows menu of X11.app. I used expose and spaces (I have 2x2) to look for the xlogo window but cannot find it. I cannot by clicking or using the Windows menu item get xterm to have focus again. I tried some slight variations to the above they all had the same results but in one case X11.app got a spinning beach ball. If I set the X11.app pref to use same depth as Aqua I have no problems. I am using rootless mode. My work around is to continue to use Xvnc for 8-bit. Otherwise I have had good results so far with 2.3.3.2 on a 32-bit intel and this G4, thanks again. mzs

2 1

.xinitrc.d
by Christof Wolf 19 May '09

19 May '09

On Tuesday 19 May 2009, xquartz-dev-request(a)lists.macosforge.org wrote: > By making your own ~/.xinitrc file, you're missing out on all the > setup steps that are taken in the system xinitrc. Jeremy, I have on my system .xinitrc.d/90-kde.sh . /sw/bin/init.sh export KDEWM=quartz-wm exec /sw/bin/startkde &> /tmp/kde.log but, it does not start kde - you can't even start any kde program within a terminal, if I use my old .xinitrc - it does load the kde manager and all kde programs are running in a terminal. . /sw/bin/init.sh export KDEWM=quartz-wm /sw/bin/startkde>/tmp/kde.log 2>&1 any idea? both files have the same rights and ownership (644) ciao christof -- public key www.hfph.mwn.de/~chwolf/chwolf.asc Please respect my privacy and do not make my contact information available to third parties.

2 2

Re: [Xquartz-dev] Leopard X11 Update 2.3.3.1
by Jeremy Huddleston 18 May '09

18 May '09

>> 1) Don't use ~/.xinitrc. Use ~/.xinitrc.d instead > > I guess I don't see the point. Why do I need a directory? By making your own ~/.xinitrc file, you're missing out on all the setup steps that are taken in the system xinitrc. If you create a ~/.xinitrc.d directory with files in it, those files get sourced after the system ones.

1 0

Re: [Xquartz-dev] Leopard X11 Update 2.3.3.1
by Jeremy Huddleston 18 May '09

18 May '09

That sounds about right. On May 17, 2009, at 20:41, Bill Janssen wrote: > Should there really be 931 visuals when I run this new server? > > All appear to be 24 bit DirectColor. > > Bill

2 4

2.3.3.2 [Was Re: XQuartz 2.3.3.1 & Spaces]
by Jeremy Huddleston 18 May '09

18 May '09

Here's the promised release to fix the spaces interaction bug in 2.3.3.1... http://xquartz.macosforge.org/trac/wiki/X112.3.3.2 http://xquartz.macosforge.org/downloads/X11-2.3.3.2.dmg /wear brown-paper-bag --Jeremy On May 17, 2009, at 16:08, Jeremy Huddleston wrote: > ugg... face/palm ... I'll have a brown-bag fix for that. > > On May 17, 2009, at 15:48, Richard Cobbe wrote: > >> I upgraded to MacOS 10.5.7 a while back and to XQuartz 2.3.3.1 >> today. I'm >> having some difficulty with the interaction between Spaces and >> XQuartz. >> (Forgive me please if this has already been discussed on the list; >> I did a >> quick trawl through the archives and open bug reports but couldn't >> find >> anything.) >> >> I have Spaces configured with the default 2x2 layout, and with all >> X11 >> windows appearing on space #1. Before the upgrade (XQuartz >> 2.3.2.1, I >> believe), this behaved in the way that I'd expect: using cmd-tab to >> switch >> to X11 switched to space #1 and brought all X windows to the >> foreground. >> All new X11 windows (clients and support windows, like the >> preferences box) >> appeared on space #1. >> >> Now, things are weird. This is still fairly new and complicated, >> so I may >> be missing some details, but here's what I've observed: >> >> - When I start a new X client, it appears on Space #1, as I expect. >> >> - X server support windows (preferences, About X11) appear on space >> #1, >> and opening these causes the computer to switch to space #1. >> >> - If I'm looking at another app on Space #3 (say) and activate X11 >> with >> cmd-tab, then the computer does *not* change to space #1 but >> instead >> moves all existing X client windows to the foreground of the >> current >> space. X has input focus. If I have an X support window open, >> that >> does *not* move to the new space. >> >> - If I'm running X in Space #3, say, and I open a new X client, it >> appears on space #1 as above. But the computer does not switch to >> space #1; it stays on space #3. >> >> Bullet points 1 & 2 are the expected behavior. Bullet point 3 is >> the big >> problem; without it, #4 goes away. >> >> Unfortunately, because I didn't upgrade MacOS and Xquartz at the >> same time, >> I can't say for sure whether it's the OS or X server upgrade that >> caused >> the change in behavior. I *think* it's the X server upgrade. >> Also, FWIW, >> after the X server upgrade, I did restart the X server, but I haven't >> logged out or rebooted the machine (which no longer seem to be >> required >> steps in the process). >> >> Is there a workaround? Should I file a bug report? >> >> Thanks, >> >> Richard >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> X11-users mailing list (X11-users(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/x11-users/jeremyhu%40freedesktop.org >> >> This email sent to jeremyhu(a)freedesktop.org > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > X11-users mailing list (X11-users(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/x11-users/jeremyhu%40freedesktop.org > > This email sent to jeremyhu(a)freedesktop.org

1 0

Re: [Xquartz-dev] Leopard X11 Update 2.3.3.1
by Jeremy Huddleston 18 May '09

18 May '09

On May 17, 2009, at 20:39, Bill Janssen wrote: > Hmmm. I just updated my laptop and my desktop to 10.5.7, then to X11 > 2.3.3.1. Laptop seems fine; X runs as normal on login. > > But on my desktop, if I click the /Applications/Utilities/X11.app, or > put it in my Login Items, it appears for a few seconds, then > disappears. > In my log file (my .xinitrc keeps this log file), I find this message: > > Error: another clipboard is already running > > This is from xclipboard, which I run as the "blocking" client at the > end > of the .xinitrc file. Well that's your problem. 1) Don't use ~/.xinitrc. Use ~/.xinitrc.d instead 2) Let the WM be the exec'd application, not a clipboard manager. 3) If you want to use xclipboard, you need to disable some of xpbproxy's behavior. Look in X11->Preferences->Clipboard > So is this release already automagically running a clipboard or > pasteboard? I don't really understand this question. > Is this built into quartz-wm now? The pasteboard proxying was being done by quartz-wm. As of 2.3.2, it is done entirely by a thread in the Xserver (an updated version of the code that was formerly in quartz-wm) with support for proxying CLIPBOARD. > What's weirder is that if I start Terminal, then start an xterm from > that, the whole X11 server and my .xinitrc start up just fine. Maybe xclipboard is winning the race in this case.

1 0

Leopard X11 Update 2.3.3.1
by Jeremy Huddleston 17 May '09

17 May '09

A small bug was found in 2.3.3 that could cause the X server to crash when closing a window. This is a rare occurrence and requires a tad bit of (un)lucky timing to trigger, but I thought it best to make the fix available. Version 2.3.3.1 brings in a small update to dri2proto and xinput in addition to this crash fix: http://xquartz.macosforge.org/trac/wiki/X112.3.3.1 --Jeremy

1 0

Re: [Xquartz-dev] What's the story with Xaw3d?
by Peter Dyballa 16 May '09

16 May '09

Am 13.05.2009 um 18:48 schrieb Ken Preslan: > I don't think the dependencies for emacs+x11 are quite right. I've > seen > the same thing after upgrading the port for some low-level X11 > library. > Uninstalling emacs and reinstalling it has always fixed it for me, > though. Recent Emacsen use GTK+2 as default in X11. Which is a pity. A private version of the port file might be a solution ... -- Greetings Pete In a world without walls and fences, who needs gates and windows?

3 5