[Xquartz-dev] GLX updates on 2.3.2_rc2

[Jeremy Huddleston]

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 at mac.com
>
>
> "Be well, do good work, and keep in touch." - Garrison Keillor
>
>
>
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev