April 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

Re: [Xquartz-dev] X11 2.3.3 OS-X Requirements OS-X 10.5.7 or later is required
by Jeremy Huddleston 28 Apr '09

28 Apr '09

No, you're seeing it right. The SU thrashes the X11 update. I wanted to require 10.5.7, so you are forced to update the OS first. I was under the impression that 10.5.7 was released to the public last week. I was in error there. Just hold tight and install 2.3.3 once 10.5.7 is publicly released or just stick with the latest 2.3.3 release candidate which works on 10.5.6 --Jeremy On 04/27/2009 02:00 PM, ~:'' ありがとうございました。 wrote: > X11 2.3.3 OS-X Requirements OS-X 10.5.7 or later is required > http://xquartz.macosforge.org/trac/wiki/X112.3.3 > > jeremy > > I checked both ppc and intel, the latest public version of os x would > appear to be 10.5.6 > is "X11 2.3.3 OS-X Requirements OS-X 10.5.7 or later " > a typo? > > or am I missing something? > > regards > > ~:" > > for whatever reason, the file: > http://xquartz.macosforge.org/downloads/X11-2.3.3.dmg > is taking 'forever' to download about 40 minutes on a 8Mb line. > this was tested during the download and reported as 3.78Mb > about 10x longer than gimp or inkscape... > > so in an inspired moment I checked the specs.

1 0

X11 vs freeglut 2.6.0-rc1
by Jack Howarth 27 Apr '09

27 Apr '09

While attempting to build some test packaging for the new freeglut 2.6.0-rc1 release on Intel Darwin, I discovered that their build fails in the freeglut demo programs with the error... Making all in smooth_opengl3 gcc -DHAVE_CONFIG_H -I. -I../../.. -I/sw/include -I../../../include -I/usr/X11R6/include -O3 -DTARGET_HOST_POSIX_X11 -c -o smooth_opengl3-smooth_opengl3.o `test -f 'smooth_opengl3.c' || echo './'`smooth_opengl3.c smooth_opengl3.c:101: error: redefinition of typedef 'PFNGLGENBUFFERSPROC' /usr/X11R6/include/GL/gl.h:1884: error: previous declaration of 'PFNGLGENBUFFERSPROC' was here smooth_opengl3.c:104: error: redefinition of typedef 'PFNGLBINDBUFFERPROC' /usr/X11R6/include/GL/gl.h:1882: error: previous declaration of 'PFNGLBINDBUFFERPROC' was here smooth_opengl3.c:107: error: redefinition of typedef 'PFNGLBUFFERDATAPROC' /usr/X11R6/include/GL/gl.h:1886: error: previous declaration of 'PFNGLBUFFERDATAPROC' was here smooth_opengl3.c:110: error: redefinition of typedef 'PFNGLCREATESHADERPROC' /usr/X11R6/include/GL/gl.h:1939: error: previous declaration of 'PFNGLCREATESHADERPROC' was here smooth_opengl3.c:113: error: redefinition of typedef 'PFNGLSHADERSOURCEPROC' /usr/X11R6/include/GL/gl.h:1940: error: previous declaration of 'PFNGLSHADERSOURCEPROC' was here smooth_opengl3.c:116: error: redefinition of typedef 'PFNGLCOMPILESHADERPROC' /usr/X11R6/include/GL/gl.h:1941: error: previous declaration of 'PFNGLCOMPILESHADERPROC' was here smooth_opengl3.c:119: error: redefinition of typedef 'PFNGLCREATEPROGRAMPROC' /usr/X11R6/include/GL/gl.h:1942: error: previous declaration of 'PFNGLCREATEPROGRAMPROC' was here smooth_opengl3.c:122: error: redefinition of typedef 'PFNGLATTACHSHADERPROC' /usr/X11R6/include/GL/gl.h:1943: error: previous declaration of 'PFNGLATTACHSHADERPROC' was here smooth_opengl3.c:125: error: redefinition of typedef 'PFNGLLINKPROGRAMPROC' /usr/X11R6/include/GL/gl.h:1944: error: previous declaration of 'PFNGLLINKPROGRAMPROC' was here smooth_opengl3.c:128: error: redefinition of typedef 'PFNGLUSEPROGRAMPROC' /usr/X11R6/include/GL/gl.h:1945: error: previous declaration of 'PFNGLUSEPROGRAMPROC' was here smooth_opengl3.c:131: error: redefinition of typedef 'PFNGLGETSHADERIVPROC' /usr/X11R6/include/GL/gl.h:1969: error: previous declaration of 'PFNGLGETSHADERIVPROC' was here smooth_opengl3.c:134: error: redefinition of typedef 'PFNGLGETSHADERINFOLOGPROC' /usr/X11R6/include/GL/gl.h:1972: error: previous declaration of 'PFNGLGETSHADERINFOLOGPROC' was here smooth_opengl3.c:137: error: redefinition of typedef 'PFNGLGETPROGRAMIVPROC' /usr/X11R6/include/GL/gl.h:1970: error: previous declaration of 'PFNGLGETPROGRAMIVPROC' was here smooth_opengl3.c:140: error: redefinition of typedef 'PFNGLGETPROGRAMINFOLOGPROC' /usr/X11R6/include/GL/gl.h:1973: error: previous declaration of 'PFNGLGETPROGRAMINFOLOGPROC' was here smooth_opengl3.c:143: error: redefinition of typedef 'PFNGLGETATTRIBLOCATIONPROC' /usr/X11R6/include/GL/gl.h:1981: error: previous declaration of 'PFNGLGETATTRIBLOCATIONPROC' was here smooth_opengl3.c:146: error: redefinition of typedef 'PFNGLVERTEXATTRIBPOINTERPROC' /usr/X11R6/include/GL/gl.h:1930: error: previous declaration of 'PFNGLVERTEXATTRIBPOINTERPROC' was here smooth_opengl3.c:149: error: redefinition of typedef 'PFNGLENABLEVERTEXATTRIBARRAYPROC' /usr/X11R6/include/GL/gl.h:1931: error: previous declaration of 'PFNGLENABLEVERTEXATTRIBARRAYPROC' was here smooth_opengl3.c:152: error: redefinition of typedef 'PFNGLGETUNIFORMLOCATIONPROC' /usr/X11R6/include/GL/gl.h:1974: error: previous declaration of 'PFNGLGETUNIFORMLOCATIONPROC' was here smooth_opengl3.c:155: error: redefinition of typedef 'PFNGLUNIFORMMATRIX4FVPROC' /usr/X11R6/include/GL/gl.h:1966: error: previous declaration of 'PFNGLUNIFORMMATRIX4FVPROC' was here smooth_opengl3.c: In function 'main': smooth_opengl3.c:425: error: 'GLUT_FORWARD_COMPATIBLE' undeclared (first use in this function) smooth_opengl3.c:425: error: (Each undeclared identifier is reported only once smooth_opengl3.c:425: error: for each function it appears in.) smooth_opengl3.c:425: error: 'GLUT_DEBUG' undeclared (first use in this function) make[4]: *** [smooth_opengl3-smooth_opengl3.o] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 This appears to be coming from the definitions that exist in our gl.h. These definitions don't exist in the gl.h of Fedora 10 but are in glext.h instead. I noticed we have the comment... /* The following macros exist to address conflicts between the names given to * function pointers by the MESA API and OpenGL.framework's API. */ We should probably make the freeglut developers aware of this issue so we don't have to heavily patch the freeglut 2.6.0 release. Any particular comments on this? Jack

3 8

10.5.7 and X11
by Chupacerveza 24 Apr '09

24 Apr '09

Having missed the previous e-mail, I'm confused about obtaining 10.5.7. (I don't see it as an available update.) This link fails to produce anything useful: http://www.opensource.apple.com/darwinsource/10.5.7/ I do note that the 2.3.3 binary installer requires 10.5.7 though. --Robert > I strongly recommend that if you have been using updates from http://xquartz.macosforge.org > , you install the 2.3.3 release after updating to 10.5.7 (see my > previous email).

2 1

10.5.7 and X11
by Jeremy Huddleston 23 Apr '09

23 Apr '09

I strongly recommend that if you have been using updates from http://xquartz.macosforge.org , you install the 2.3.3 release after updating to 10.5.7 (see my previous email). Now, for those interested, I'd like to summarize the changes that went into 10.5.7. The X11 server in 10.5.7 is very similar to what is shipped in 2.3.2.1. 2.3.2.1 shipped xorg-server-1.4.2-apple31, 10.5.7 uses xorg-server-1.4.2-apple33 plus the capslock fix. libGL is still the "old" libGL based off of mesa during the xfree86 era with some fixes along the way. Xplugin was updated to address some memory leaks and add API needed by this server update. quartz-wm was updated to almost what was shipped in 2.3.3. The only difference between the 10.5.7 version and the 2.3.3 version is that 10.5.7's doesn't call the new XAppleWMSendPSN() function in libAppleWM. For most of you, this will mean nothing. For those of you running more than one server at a time, this means that 10.5.7 still has the "sometimes clicking on the minimized dock icon doesn't raise a window" bug. The rest of the client side was updated only where necessary to satisfy a dependency (pixman I believe was updated for the server), fix build issues (Xrandr, Xdamage), or address security issues (freetype, libpng... you know, the regular offenders). If you have any specific questions about what is in the update, feel free to ask or just look yourself: http://www.opensource.apple.com/darwinsource/10.5.7/ Note that the link doesn't seem to be active yet, but it should be valid in the next few days. --Jeremy

1 0

Release: X11 For Leopard 2.3.3
by Jeremy Huddleston 23 Apr '09

23 Apr '09

Thanks to all the users who have been testing during this release cycle. Version 2.3.3 has matured to a great state with much improved support for GLX, better input handling, support for AFP home systems, better support for session managers like gnome and kde, and translation updates. Please test these new localizations and provide feedback if you use them. This release addresses CVE-2009-0040 in libpng: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0040 Full release notes: http://xquartz.macosforge.org/trac/wiki/X112.3.3 Direct link to dmg: http://xquartz.macosforge.org/downloads/X11-2.3.3.dmg

1 0

libGL.1.2.dylib shipped with 2.3.3 RC5 makes applications crash
by vmrsss 23 Apr '09

23 Apr '09

Hello > Changed 3 hours ago by jeremyhu@… > • status changed from new to closed > • resolution set to worksforme > Please bring this up on xquartz-dev for faster iteration and more > eyes. > As required, I am bringing this to the developer list. Please find below my original report and attachment. > This bug report is vague and I can't really do anything about it > without specifics. > Yes, that's right and I am aware of it. Unfortunately, I am not acquainted at all with XQuartz. > Please give me examples of applications that fail with the new libGL. > (OK, but let's postpone this a bit longer) > mplayer is not a good example as it's not using GLX. It's using > OpenGL.framework directly. > Well, that cannot be, because as I link /usr/X11/lib/libGL.1.2.dylib to the new (resp old) dylib mplayer keeps crashing (resp works just fine). I suppose the key here is to run mplayer -vo macosx (as eg mplayer -vo x11 works). Have you tried that? This activates vo_macosx.m which uses libGL, eg: "nm -a vo_macosx.o" list includes: > U _glBegin > U _glBindTexture > U _glClear > U _glColor3f > U _glColor4f > U _glDepthMask > U _glDisable > U _glEnable > U _glEnd > U _glFlush > U _glLoadIdentity > U _glMatrixMode > U _glOrtho > U _glTexCoord2f > U _glVertex2i > U _glViewport Can it be that the dylib system get confused with different versions of libGL.1.2? I have just noticed something which is likely to be significant: the old libGL (the one which works) appears to link a libGL.dylib v1.0 from the OpenGL framework, while the new libGL, doesnt: > $ otool -L /usr/X11/lib/libGL.1.2.dylib.new > /usr/X11/lib/libGL.1.2.dylib.new: > /usr/X11/lib/libGL.1.dylib (compatibility version 1.2.0, current > version 1.2.0) > /usr/lib/libXplugin.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > ApplicationServices (compatibility version 1.0.0, current version > 34.0.0) > /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current > version 11.0.0) > /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current > version 9.0.0) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 111.1.3) > $ > $ otool -L /usr/X11/lib/libGL.1.2.dylib.old > /usr/X11/lib/libGL.1.2.dylib.old: > /usr/X11/lib/libGL.1.dylib (compatibility version 1.2.0, current > version 1.2.0) > /usr/lib/libXplugin.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ > libGL.dylib (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > ApplicationServices (compatibility version 1.0.0, current version > 34.0.0) > /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL > (compatibility version 1.0.0, current version 1.0.0) > /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current > version 11.0.0) > /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current > version 9.0.0) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 111.1.3) > Regards, -vmrsss Begin forwarded message: > From: "XQuartz" <trac(a)macosforge.org> > Date: 22 April 2009 21:51:02 BST > To: undisclosed-recipients:; > Subject: [XQuartz] #259: libGL.1.2.dylib shipped with 2.3.3 RC5 > makes applications crash > Reply-To: noreply(a)macosforge.org > > #259: libGL.1.2.dylib shipped with 2.3.3 RC5 makes applications crash > ------------------------------ > +--------------------------------------------- > Reporter: vmrsss@… | Owner: jeremyhu@… > Type: crash | Status: new > Priority: major | Milestone: 2.3.3 > Component: x11-libs | Version: dev (xorg-server-1.4- > apple) > Keywords: | > ------------------------------ > +--------------------------------------------- > Hello. I am unsure whether to raise a ticket or email xquartz-dev, > as I > don't know that the one I am reporting is a bug. Please bear with me. > > Is X11-2.3.3 supposed to be backward compatible? I have installed > it, and > found that a number of applications which use /usr/X11/lib/libGL. > 1.dylib > crash. I have also verified that replacing libGL.1.2.dylib with the > corresponding file from X11-2.3.2.1, the applications seem to run well > again (incidentally, I found strange that the two version of the > library > are very different in size: 2.3M for 2.3.2.1, against 798K for 2.3.3). > > Is this expected? I wouldn't think so, or there would at least have > been a > bump version number of GL. So, is it a bug to be fixed in X11-2.3.3? > > I attach below the output of GDB in the case of one crash (of the > open- > source application mplayer). I don't think it is particularly > useful, it > doesn't am happy to help debug, but I need to be instructed about > what > information/tests you may need. > > Question: is it safe to downgrade to 2.3.2.1 by simply installing > X11-2.3.2.1 on top of 2.3.3.RC5, or should I remove /usr/X11 entirely > before reinstalling? Thx

3 8

GLX stereo and old hardware: request for enable_stereo
by Martin Otte 21 Apr '09

21 Apr '09

I just wanted to post a summary of my problem where the latest X11 server on Tiger says that it can do stereo glx visuals, but any program that attempts to create a stereo window crashes. I tested with a non-X11 CGL program, and I get the same behavior. The problem is that my computer (Powerbook G4, OSX 10.4.11) advertises that opengl can do stereo, but it can only do stereo in full screen mode, not per-window. Since Apple's opengl says that it can do stereo, the X server sets up all of the stereo glx visuals. But just like the native CGL programs that I tried, any glx program that tries to create a windowed stereo visual crashes with an error because it is not full screen. I don't know if this is specifically a problem with Tiger or with older hardware. An old G4 tower with an ATI video card running 10.4 displays the same behaviour. I must have run into this problem before because I had set enable_stereo to false in my x11 preferences, but this option seems to be ignored with the recent X11 servers. Can you bring back the enable_stereo preference option? It should default to true it not set, but allow one to turn off stereo visuals if the older hardware wrongly advertises that it can do stereo. Thanks, Martin

3 3

Clipboard proxying stopped working after a few days
by Martin Otte 21 Apr '09

21 Apr '09

It has happened to me twice (once with 2.3.3_rc5, xorg-server 1.4.2- apple41 and the other time on a Tiger machine with a macports x11- server 1.4.2-apple41) that all clipboard proxying from X11 to the mac clipboard stopped working. It only happened after X11 had been running for a few days straight, but I saw no suspicious errors or warnings in the console log. I suspect that switching to a different user and/or putting the machine to sleep might have induced this, but this is only a guess. In the X11 Pasteboard preferences, I have all of the options checked. Out of habit, I usually do a Command-C in X11 when I want to transfer some text to the mac clipboard, but for these two times even the Command-C no longer worked. It was as if the X11 server completely lost communication with the mac clipboard. Quitting and restarting X11 brought back the clipboard proxying. Have you seen or heard about any behavior like this, or is there any changes in 1.4.2-apple42 that may affect this? Thanks, Martin Otte

1 0

problem solved :-)
by Christof Wolf 13 Apr '09

13 Apr '09

Jeremy, I tested 2.3.3-rc5 with 1.5.3apple6 and 2.3.3 with apple42 - no problem with the Wacom tablet, no crazy CPU!! both installations work fine on my system. No problem with KDE so far :-) I mainly use Kmail :-) good luck for your theses! take care 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.

1 0