Mac driver status: ready for contributions
ken at codeweavers.com
Tue Mar 19 06:09:22 CDT 2013
On Mar 19, 2013, at 1:31 AM, Charles Davis wrote:
> I have one more of my own to add:
> * Fix crash whenever an app makes a GLU call.
Ah, yes, I forgot that one. Thanks for reminding me.
> I suspect this is because Mesa's GLU calls Mesa's libGL--which crashes horribly because there's no Mesa/GLX context current.
> I see two ways to fix that. One is to make GLU dispatch go through the driver.
This is what I did for CrossOver 12. The problem is that it introduced a requirement that a WGL context be current on the thread to find the driver functions. (Technically, the GLU spec requires a current GL context at the time of any GLU calls, but glu32 doesn't require that and, empirically, it seems that Mesa's library doesn't either. Because some stuff that used to work was broken by CrossOver 12.)
> The other is to actually implement glu32 (i.e. not as a forwarder to the system GLU). I'm not sure how AJ will feel about the first one--and I probably won't know until next week.
Not thrilled, although willing to entertain it if it can be done in a relatively elegant and robust way. None of my proposals rose to those standards. ;)
> The second one... writing a GLU is a lot of work. We could use SGI's (as Mesa does), but SGI GLU is largely written in C++--and I *know* AJ won't like that.
Implementing glu32 on top of opengl32 was Alexandre's approach. He was looking for an open-source GLU implementation to use. He could find C implementations for most parts of GLU except the NURBS stuff.
We didn't really get any further than that.
More information about the wine-devel