On Thursday 11 May 2006 14:24, Tomas Carnecky wrote:

> Alexandre Julliard wrote:

> > Tomas Carnecky <tom@dbservice.com> writes:

> >> As far as I understand, the only way to access x11drv is through GDI

> >> (which implements ExtEscape), would your proposed change require new

> >> functions for opengl32 <-> x11drv communication through GDI? Or is it

> >> somehow possible to bypass GDI and access x11drv directly from opengl32?

> >

> > The DC access will have to be done through GDI, yes, but that can be a

> > simple wrapper that calls the corresponding driver entry point. For

> > functions that don't need to access the DC, opengl could call x11drv

> > directly, though of course if everything goes through GDI it will make

> > it easier to support opengl with a different driver.

>

> Based on your ideas, I did the following:

> - added a new gdi driver function: 'wglMakeCurrent'

> - move wglMakeCurernt to x11drv

> - new function wrapper_wglMakeCurrent in gdi/driver.c

> - wglMakeCurrent in opengl32 just calls wrapper_wglMakeCurrent

>

> and it works, though I had to add -lGL to the x11drv Makefile, I don't

> know how you see a libGL.so requirement for x11drv, maybe load libGL.so

> and the required entry points at runtime like in opengl32/wgl.c

No x11drv should not depend to GL.so. see opengl.c

you can see that GL.so is dynamically loaded (dlopen/dlsym)

so not mandatory

> I had to simplify wglMakeCurrent, I didn't spend much time on this hack,

> and I had to copy the Wine_GLContext structure to x11drv/opengl.c, quite

> ugly.. I know

well ...

> I also had to comment out calls to 'NtCurrentTeb()' because it wouldn't

> compile otherwise, I don't know what that function does, but World of

> Warcraft works without it (and as a sidenote, I think it runs much faster).

Yakkk

NtCurrentTeb is used to access current thread descriptor as opengl contexts are thread-specific. And it sould permit to share opengl context between many wine ibraries (as windows do) without ugly hacks :)

> I didn't know how much logic to put into opengl32/gdi or x11drv, gdi

> extracts the PHYSDEV from the HDC and passes it as the first argument to

> the x11drv function implementation, along with the original arguments

> (Is is ok to pass HDC to the x11drv?).

>

> And I don't know if the function naming is ok, x11drv exports a function

> named wglMakeCurrent, maybe that should be changed to

> wine_wglMakeCurrent and I don't know if the gdi wrapper and exported

> function names (both wrapper_wglMakeCurrent) are ok.

>

> If we can sort out the naming I could start adding the driver entry

> points to both GDI and x11drv, without migrating the actual function

> implementation, and than start migrating function by function to x11drv.

>

For info in windows openGL32.dll prerequs:

- user32.dll

- gdi32.dll

- ddraw.dll

I'll look at patch when i'll have time (too little for now)

Thx

Regards,

Raphael