PBuffer and wglMakeCurrent()

[Tomas Carnecky]

In wglMakeCurrent(), when the HDC type is OBJ_MEMDC you activate the
frontbuffer for drawing. PBuffers' type is also OBJ_MEMDC, but changing
the drawbuffer in that case is wrong.

Is there a way to find out if the HDC is a PBuffer? I have some patches
in my local tree but I took the freedom to put the X11DRV escape codes
to one common header which alexandre doesn't quite like..
In my local tree I have a 'flags' field in X11DRV_PDEVICE which I use to
store whether the PBuffer is damaged or not, I don't know if its the
right place, but I could add a flag IS_PBUFFER and set it in
wglGetPbufferDCARB() and check for it in wglMakeCurrent().

comments?

tom

[Tomas Carnecky]

Tomas Carnecky wrote:
> comments?

Why do I have the impression that when it comes to x11drv/opengl nobody
wants to take the responsibility. I won't submit a patch until someone
says 'tom, your approach looks good, improve this and then submit a
patch to wine-patches' or 'tom, no, this won't work because ... try to
change this ... move the code there ... don't do that, it will break
this' etc.
I don't want to know whether the implementation details are ok, I just
want to know whether the general idea (the flags field) is acceptable.

I did the changes I've described and it does work, but I won't work on
it any further (eg. make it independent of my previous patches) unless I
get a green light.

In the attachment is the latest patch I've applied to my local tree, you
see that it requires the X11DRV_[S|G]ET_FLAGS escape code which I've
added in one of my previous patches. Maybe that gives you an better idea
of what I'm trying to do.

tom

[Alexandre Julliard]

Tomas Carnecky <tom(a)dbservice.com> writes:
> Why do I have the impression that when it comes to x11drv/opengl nobody
> wants to take the responsibility. I won't submit a patch until someone
> says 'tom, your approach looks good, improve this and then submit a
> patch to wine-patches' or 'tom, no, this won't work because ... try to
> change this ... move the code there ... don't do that, it will break
> this' etc.
> I don't want to know whether the implementation details are ok, I just
> want to know whether the general idea (the flags field) is acceptable.

What we probably want is to move a lot more of the glX code into
x11drv, and export the various wgl functions from there. That escape
mechanism is beginning to be seriously abused.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Tomas Carnecky]

Alexandre Julliard wrote:
> What we probably want is to move a lot more of the glX code into
> x11drv, and export the various wgl functions from there. That escape
> mechanism is beginning to be seriously abused.

Even is the functions were implemented in x11drv.. wglMakeCurrent()
still takes a HDC as an argument so the issue how to change the
X11DRV_DEVICE given a HDC would remain. The escape mechanism seems to be
the only way to communicate with the low-level x11drv implementation, or
did I miss something?
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?

tom

[Alexandre Julliard]

Tomas Carnecky <tom(a)dbservice.com> writes:
> Even is the functions were implemented in x11drv.. wglMakeCurrent()
> still takes a HDC as an argument so the issue how to change the
> X11DRV_DEVICE given a HDC would remain. The escape mechanism seems to be
> the only way to communicate with the low-level x11drv implementation, or
> did I miss something?
> 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.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Tomas Carnecky]

Alexandre Julliard wrote:
> Tomas Carnecky <tom(a)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

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

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).

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.

The attached patch is what came up by my hacking, just so you have an
idea what I've done ;)

tom

[Raphael]

On Thursday 11 May 2006 14:24, Tomas Carnecky wrote:
> Alexandre Julliard wrote:
> > Tomas Carnecky <tom(a)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