2.3.2 is going to be an attempt to make GLX as good as possible with fixes to the current libGL and the 1.4 branch of xorg-server. After we push it out, I expect to devote full energy to the 1.5 server branch. GLX had some major changes between 1.4 and 1.5, and we're fairly limited in what we can do using the 1.4 branch (mainly, we're stuck at GLX 1.2, so no pbuffer support will appear until we move to 1.5). George can fill in the lines here with more details if you're curious. The next major release should be 2.4.0 based off the xorg-server-1.5- apple branch and a major update to libGL that George has been working diligently on. My advise to you is to thoroughly test your use of GLX in this release for regressions over 2.3.1. There is just one regression that I'm aware of that is blocking the release of 2.3.2, so hopefully we'll have that done soon, but in the mean time, test test test... but the golden egg for you should hopefully be 2.4.0, so keep up with the 2.4.0 alphas, betas, and rcs as they come out to help us make the new libGL work as well as possible for your apps. Thanks, Jeremy On Nov 30, 2008, at 12:35, ryan woodsmall wrote:
Jeremy, George, et al:
Thanks so much for your work on X11 under Leopard! I do a lot of SSH-tunneled X forwarding from Linux servers to my MacBook at my job, and your work has made X not only more stable, but a treat to use. Kudos.
As far as "play" goes, I'm attempting to make open source Wine work with straight X11, including OpenGL/Direct3D support. Wine itself works great for running the few Windows apps I need that have no Mac/ Linux counterparts, but I'm still running into some problems - likely known - with Wine running games. This issue was marked fixed with the recent 2.3.2_rc2 release:
http://xquartz.macosforge.org/trac/ticket/122
I can indeed see the GLX_SGIX_fbconfig extension, but it fails to initialize automatically in Wine. When forcing Wine to use the GLX_SGIX_fbconfig path by #ifdef'ing a section of source in the X11 OpenGL driver, there's still a crash when initializing a Wine client like, say, Steam to run a Direct3D game. I'd bet this is related to the following open issues, but I could be completely wrong:
http://xquartz.macosforge.org/trac/ticket/135 http://xquartz.macosforge.org/trac/ticket/140 http://xquartz.macosforge.org/trac/ticket/196
Using a Wine-ified version of the realtech Windows OpenGL Extensions viewer doesn't cause a full crash of the process, but the program warn of attempting to read from an unknown part of memory address. This looks to be an attempt to use a function pointer to a GL/GLX function that's not present.
As always, debugging Wine is something of a nightmare - there are so many jumps to different areas that it's hard to even track exactly where in the code the crash is occurring. I have some experience with C and OpenGL, but little with direct X or GLX coding, so I'm grasping a bit to understand everything here. Before digging too deep for my own good in Wine, should I expect most GLX stuff to "just work" at this point, or is this an exercise in futility until the OpenGL.framework DRI work is done? As this is mostly for games, and nothing in my day-to-day work requires any OpenGL/Direct3D Windows apps, even a recommendation of just wait for the DRI framework would suffice, though any advice would be greatly appreciated.
Thanks again!
ryan woodsmall rwoodsmall@mac.com
"Be well, do good work, and keep in touch." - Garrison Keillor
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev