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

Xcode 3.1.3 issues?
by Dave Ray 22 Jun '09

22 Jun '09

Just wondering if there are any issues with the newly released Xcode 3.1.3 clobbering X11 files. Do I need to reinstall anything?

2 1

Re: [Xquartz-dev] Bug in displaying vtk objects
by Jeremy Huddleston 17 Jun '09

17 Jun '09

This is really better suited for xquartz-dev, so moving there... >> The result for Valerie's vtk scripts is the same as with 2.3.3.2, >> with one exception: The "correct" vtk window from imagepluspoly.py >> now renders extremely slowly, it follows mouse movements with about >> 1 frame per second. > > Whoa. it must be triggering something bad in our old libGL to be > seeing such low performance. > > There were some changes in 2.3.2, so I'd also try 2.3.1 and start > stepping back towards 2.2.3 (which was pretty much what was in OSX > 10.5.5) to see if any of those make a difference. > >> With 2.3.3.2 it is fluid, as are (with both 2.3.2 and 2.3.3.2) the >> "wrong" windows using gtk that do not show the volume object. >> >> My configuration is similar to Valerie's, same Mbook pro, same >> GeForce 8600M GT graphics card. VTK is more up-to-date: >> >> vtk: 5.4 (fink package vtk54-5.4.0-1) >> >> but this doesn't seem to make a difference. > > I just got back from my trip, so I'm going to try reproducing this. > I'm a MacPorts guy, so I'm installing our vtk5 port right now. MP > doesn't have a vtk-py port, so I'll need to put one together first > assuming vtk5 builds alright here. So it turns out the vtk-py stuff is in MacPorts' vtk5 port already, so I'm giving it a go. The two gtk scripts fail outright for me using MacPorts with either Mesa's libGL or our new hardware accelerated libGL. I see: The program 'gtkvtkdebug2.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 20 error_code 2 request_code 0 minor_code 3) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Here's the stack with our hw accelerated libGL: #0 0x0072e08c in gdk_x_error () #1 0x018e274c in _XError () #2 0x055adfa4 in __glXSendError (dpy=0x8af400, errorCode=2, resourceID=34, minorCode=3, coreX11error=true) at glx_error.c:59 #3 0x055809f4 in CreateContext (dpy=0x8af400, vis=0x7322e40, fbconfig=0x0, shareList=0x0, allowDirect=1, contextID=0, use_glx_1_3=0, renderType=0) at glxcmds.c:388 #4 0x05580b30 in glXCreateContext (dpy=0x8af400, vis=0x7322e40, shareList=0x0, allowDirect=1) at glxcmds.c:416 #5 0x0534a2b0 in vtkXOpenGLRenderWindow::CreateAWindow () #6 0x0534b6d4 in vtkXOpenGLRenderWindow::WindowInitialize () #7 0x0534b7f0 in vtkXOpenGLRenderWindow::Initialize () #8 0x0534bc88 in vtkXOpenGLRenderWindow::Start () #9 0x0523edc0 in vtkRenderWindow::DoStereoRender () #10 0x0523ed74 in vtkRenderWindow::DoFDRender () #11 0x0523e6f8 in vtkRenderWindow::DoAARender () #12 0x0523db58 in vtkRenderWindow::Render () #13 0x0534e9d0 in vtkXOpenGLRenderWindow::Render () #14 0x04f2e67c in PyvtkXOpenGLRenderWindow_Render () ... (gdb) frame 3 #3 0x055809f4 in CreateContext (dpy=0x8af400, vis=0x7322e40, fbconfig=0x0, shareList=0x0, allowDirect=1, contextID=0, use_glx_1_3=0, renderType=0) at glxcmds.c:388 388 __glXSendError(dpy, BadValue, vis->visualid, X_GLXCreateContext, (gdb) print mode $1 = (const __GLcontextModes *) 0x0 ^^^ This is why we're seeing an error. We couldn't get a valid mode for the requested visual id: (gdb) print vis->visualid $2 = 34 So we were told to use an invalid visual by vtkXOpenGLRenderWindow::CreateAWindow I'm curious how you guys are getting yours to render. Perhaps this is an issue that is fixed in fink's version of vtk. Can you set the LIBGL_DUMP_VISUALID environment variable? that should tell you which visual is being requested, and you can find out about that visual by running 'glxinfo -v'. --Jeremy

4 4

Fwd: VTK 5.2 and GL2PS export
by Jeremy Huddleston 17 Jun '09

17 Jun '09

This just popped up on the macports-users mailing list... My guess now is that X11 isn't the culprit here since something similar is happening on Tiger without X11 as well... Begin forwarded message: > From: Jonathan Stickel <jjstickel(a)vcn.com> > Date: June 17, 2009 11:14:12 PDT > To: macports-users(a)lists.macosforge.org > Subject: VTK 5.2 and GL2PS export > > I'm experiencing a problem using the GL2PS export feature of VTK, > where VTK was installed via Macports (vtk5 @5.2.1_2+carbon > +darwin_8+python). When I have a textActor in my render window, e.g. > some arbitrary title or note, then that text does not show in the > exported pdf/eps. > > I suspect the problem might be related to the OpenGL library that > VTK links to, in this case /System/Library/Frameworks/ > OpenGL.framework/Versions/A/OpenGL since I am using the Carbon > variant. Can someone verify that they see this problem also? Any > knowledge about how to resolve this? I am currently on Tiger. > > Thanks, > Jonathan > _______________________________________________ > macports-users mailing list > macports-users(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

1 0

distinguishing stock X11 from xquartz
by Marc Bejarano 16 Jun '09

16 Jun '09

hi. what is the most straight-forward way of determining which packaged version of X11 was last installed between the ones that come with OS X and updates and the ones distributed by macosforge? i ask because i'm a VersionTracker Pro user and their developers seem to be having a hard time with this. tia, marc

2 1

2.4.0-beta2
by Jeremy Huddleston 15 Jun '09

15 Jun '09

Hi everyone, Since releasing 2.3.3, I've been spending my time working on the 1.5 server branch. I've been chipping away at the regressions that had been introduced over 1.4, and they are mostly cleared out now. Well... at least the ones I'm aware of. Two changes of note: 1) I believe a possible deadlock with 8bit visuals has been fixed that was reported in 2.3.3.2. Hopefully someone can confirm this for me. 2) I added support to quit X11 when the last window is closed. This was a requested feature a while back, so here it is. It's documented in the man page for quartz-wm, but I don't intend to make a GUI checkbox for it. defaults write org.x.X11 wm_auto_quit -bool true The full ChangeLog is available here: http://xquartz.macosforge.org/trac/wiki/ChangeLog And here's the DMG link: http://static.macosforge.org/xquartz/downloads/X11-2.4.0_beta2.dmg The only remaining known regression with this release affects users who have a ~/.Xmodmap file. There is a race condition to setup the keyboard mappings when this file is present. The results are unpredictable, and I recommend moving this file aside for the time being and running xmodmap manually once X11 has started up. Thanks, Jeremy

6 10

gimp users
by Jeremy Huddleston 14 Jun '09

14 Jun '09

Are gimp users able to use their mouse with gimp in the latest X11 release? This bug report seems to indicate that it's broken. I'm assuming it's something on gimp's end since every other application seems to work with the mouse... Begin forwarded message: > From: XQuartz <trac(a)macosforge.org> > Date: June 13, 2009 07:29:57 PDT > To: undisclosed-recipients: ; > Subject: [XQuartz] #279: XQuartz 2.3.3.2 enabled Wacom support in > Gimp, but broke mouse support > Reply-To: noreply(a)macosforge.org > > #279: XQuartz 2.3.3.2 enabled Wacom support in Gimp, but broke mouse > support > ---------------------------------- > +----------------------------------------- > Reporter: elver.loho@… | Owner: jeremyhu@… > Type: usability | Status: new > Priority: major | Milestone: > Component: xserver | Version: 2.3.3 (xserver-1.4) > Keywords: | > ---------------------------------- > +----------------------------------------- > So I finally installed 2.3.3.2 and, after some poking about in Gimp's > preferences, found a way to enable Wacom tablet support with pressure > sensitivity and everything. > > Which is quite awesome. > > Except the mouse stopped working. > > Or, rather, clicking on the canvas with any tool selected doesn't do > anything. And in the lower left corner of the canvas window the mouse > cursor's current position on the canvas is shown as negative 1.3 > million > or something like that. > > Gimp is version 2.6.1, by the way. > > I have no idea why it's broken, but having to do everything on the > tablet > with Gimp is annoying the hell out of me. > > -- > Ticket URL: <http://xquartz.macosforge.org/trac/ticket/279> > XQuartz <http://xquartz.macosforge.org/> >

4 3

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