WineGL, take two

[Kuba Ober]

On Monday 15 May 2006 13:49, Tomas Carnecky wrote:
> After submitting the patches last night, I got some feedback on IRC. It
> seems that adding new exports to gdi32.dll is bad (it apparently tends
> to break applications, those using safedisc2 seem to be good
> candidates), so I had to look for another solution.
>
> Everything that follows here is under the assumption that we want to
> move all access to the native opengl library to x11drv. But that's the
> impression I got from Alexandre in the other mail regarding new escape
> codes (http://www.winehq.org/pipermail/wine-devel/2006-May/047539.html).
>
> If the above assumption is true then opengl32.dll needs access to the
> low-level driver (eg. x11drv) where all the WGL functions are
> implemented. And if adding new gdi32.dll exports is not an option then
> ExtEscape() or some other Escape function is the only way to go. Someone
> told me that even in Windows Vista opengl uses an escape function to
> talk to the low-level driver.
>
> So my new approach is this:
> - one new gdi driver function: WineGL_getDispatchTable
>   => returns the dispatch table for the basic WGL functions.
> - two new ExtEscape() codes:
>   => WINEGL_GET_DISPATCH: returns dispatch table as returned by the new
> driver function
>   => WINEGL_GET_PRIVATE: returns physDev for the given HDC.
> - opengl32.dll gets the dispatch table using the new escape code when it
> is loaded.
> - in x11drv, opengl.c is replaced by various winegl_??? files.
>
> Why is WINEGL_GET_PRIVATE needed? The question really is: where do we
> want to have the WGL extension entry points? I'd recommend to have them
> in x11drv, why? If they were in opengl32.dll, we'd have to update the
> dispatch table whenever we would add a new extension. And because the
> application calls the functions which are entirely implemented in x11drv
> and not called through wrappers (which don't really exist in my patchset
> anyway) and the functions still need access to the physDev structure...
> well, hence the second escape code.
>
> I've removed all opengl related #ifdefs, I'd like to have configure set
> WINEGLFILES to either 'winegl_noop.c', which implements noop functions
> when opengl isn't supported, or a list with all the required winegl
> files when all required headers are present.
> And there is no need to check for linGL.so, too, (at least not for
> opengl32 and x11drv) because all functions are loaded using wine_dlsym()
> or glXGetProcAddress(). What is needed at compilation time are the three
> opengl header files gl.h, glx.h and glu.h. I'm not a configure expert
> and this big script scares me. That's why the configure patch is king of
> a hack, but should work when someone uses --without-opengl.
>
> The WGL related code is mostly copied over from opengl32/wgl.c and
> opengl32/wgl_ext.c, I've formatted it a bit to look nicer and changed
> what was needed to embed it into x11drv. For example 'get_dispay()' is
> gone as we now have direct access to the display through 'gdi_display'.
> The only thing that I've disabled is the WGL_ARB_render_texture
> extension (nvidia drivers don't support it and there is a good chance
> that no application relies explicitly on this extension, however, the
> extension can be enabled by uncommenting one line in
> x11drv/winegl_extensions.c).
>
>
> I've put all the patches, eleven to be precise, on my server:
> http://dbservice.com/ftpdir/tom/wine/
>
> up until patch number 10, it should not introduce any regression as it
> only makes the necessary changes to gdi to support the new GDI driver
> function (but doesn't use it yet) and adds the winegl files to x11drv.
> Patch number 10 is a bit large, it changes configure

Patches to configure are redundant. configure is autogenerated. Change the 
source file, namely configure.ac. 
Then do
autoconf
to generate the configure itself. You may need to run aclocal first, but I 
don't know if/when that's necessary.

First make sure that you have an autoconf version installed that is supported 
by wine. Then proceed with modifying relevant input files for autoconf.

Also, try
info autoconf

Cheers, Kuba