winex11.drv: cleanup better in X11DRV_WineGL_InitOpenglInfo

Jesse Allen the3dfxdude at
Sun Sep 17 19:01:57 CDT 2006

On 9/17/06, Phil Costin <philcostin at> wrote:
> Roderick Colenbrander wrote:
> > The problem is that I'm not sure (and I think it is Alexandre his issue
> > aswell) whether this patch is a workaround or a real fix. I think that
> > wined3d created a GLX context in lets say thread '1' and that it wants to
> > create lets say another one in a different thread. If this is the case it
> > could happen that for the new thread the x11drv visual needs to be
> > 'rechosen'. This causes the 'info' code to be called again. Because this
> > code creates a context we mess up the already active context.
> >
> > Your patch indeed fixes that by storing the current GLX context and
> > restoring it later on. Perhaps there's a nicer way to prevent this issue
> > to happen at all.
> >
> > In any case I think it might be nicer to use glXGetCurrentContext in case
> > there's already some GLX context around. So in that case don't create a
> > new context and don't kill it at the end. This would already be cleaner.
> >
> > Roderick
> >
> >
> >
> >> I don't know myself either. I was just going to wait. I want to add a
> >> little more to say about it.
> >>
> >> It's funny that the patch was only meant to affect the opengl/wgl code
> >> and the crashing apps are all d3d ones. However winex11 will now
> >> change the context on it's own when doing the opengl query and not set
> >> it back. What I noticed a couple weeks ago and now is that winex11
> >> does usually gets inited twice, therefore it will change the current
> >> context twice. One at the start of the program, and another later on
> >> -- maybe on creation of a window or something. By that time wined3d is
> >> probably inited too, and making glXMakeCurrent calls too since it's
> >> based on opengl. So perhaps winex11 is causing wined3d to trip up at
> >> some point by changing the context. So if InitOpenglInfo just sets
> >> things back, then wined3d won't go boom.
> >>
> >> >>From comments in wined3d, I can tell there isn't any "context
> >> manager". So what wined3d does at most is very simple management of
> >> contextes. We probably need a manager to coordinate things like this
> >> better between the two libraries. But that will likely be a bigger
> >> patch and to do so... I don't know, we need a fix for all the broken
> >> d3d apps now.
> >>
> >> Jesse
> >>
> >
> At the moment, this patch fixes regressions so if we don't have the code in
> there at all, many games do not work.
> It may not be the ideal solution but is it not better for now to fix the
> regression and think about a proper solution separately without breaking
> applications by not having the patch applied?
> Regards,
> Phil

Phil, Roderick,

I'm going to look at what I can do to improve the patch and gather
more information on the handling of contextes. I just haven't had time
yet. And Roderick, I'll discuss with you the newer patch when I'm
ready so to see if you agree with it. I do lean towards agreeing with
Phil on that this is simply needed and more than a workaround. I've
already been asked many times if the patch has gotten in and that is
why I posted to wine-patches so quickly; your patch broke alot of D3D
apps for alot of people...  The d3d9 stateblock test is the best clue.


More information about the wine-patches mailing list