|
On Thursday 11 May 2006 14:24, Tomas Carnecky wrote: > Alexandre Julliard wrote: > > Tomas Carnecky <[EMAIL PROTECTED]> 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 |
pgp6ZMFU07Yw6.pgp
Description: PGP signature
