Hi!
I am having trouble with OpenGL under wine (specifically Half-Life). The problem is some code in $(TOPDIR)/dlls/opengl32/wgl.c. The function wglGetProcAddress would like to call glXGetProcAddressARB, but can't, due to the DLL's initialisation routines, namely process_attach. process_attach calls glxQueryExtensionsString, and expects to find "GLX_ARB_get_proc_address" in the returned string. However, it does not find this string on my libGL and so deems that glXGetProcAddressARB is not available. The problem is that glXGetProcAddress is available and working.
The question I'm asking me now is: Is it a bug in my libGL because it is returning a wrong string, or is it a bug in wine because it is expecting something it shouldn't (there's a configure check for glXGetProcAddress as well)?
I'm running Debian 3.0r1 with an libGL built (not by me), from the dri-mach64 CVS and using the wine CVS source.
Thank you for your help with this,
Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le Tuesday 18 November 2003 23:01, Daniel Skorka a écrit :
Hi!
Hi,
The question I'm asking me now is: Is it a bug in my libGL because it is returning a wrong string, or
No, your libGL seems to implement GLX1.4
is it a bug in wine because it is expecting something it shouldn't (there's a configure check for glXGetProcAddress as well)?
Yes, wine only support GLX1.{2,3} so it expect glXGetProcAddressARB while in GLX1.4 glXGetProcAddress must be used instead
Who have the time to do a beautifull support of all versions of GLX into x11drv ? :)
I'm running Debian 3.0r1 with an libGL built (not by me), from the dri-mach64 CVS and using the wine CVS source.
Thank you for your help with this,
Daniel
Regards, Raphael
No, your libGL seems to implement GLX1.4
It's still a bug regarding 'legacy' apps... The same way as if apps start to stop reporting extensions that are now merged back into the main GL tree, they will break all the apps written before the merge.
And last time I checked, the DRI implements GLX 1.2 or 1.3 only.
Yes, wine only support GLX1.{2,3} so it expect glXGetProcAddressARB while in GLX1.4 glXGetProcAddress must be used instead
Well, let's say 'can' as the ARB version will still be exported for legacy apps :-)
Lionel
On Tue, Nov 18, 2003 at 11:01:13PM +0100, Daniel Skorka wrote:
The question I'm asking me now is: Is it a bug in my libGL because it is returning a wrong string, or is it a bug in wine because it is expecting something it shouldn't (there's a configure check for glXGetProcAddress as well)?
It's a bug in the DRI libraries that I reported some time ago and should be fixed in the XFree 4.4 (or 4.5) release of the library part of the DRI.
Note that I plan to do a work-around in the Wine code to handle bad libraries :-)
For that, could you send me the output of your 'glxinfo' ?
Lionel
Hi all,
first of all thanks for your comments on this.
Lionel: Just noticed I accidentially forgot to CC the list.
On Wed, Nov 19, 2003 at 11:04:00AM +0100, Lionel Ulmer wrote:
It's a bug in the DRI libraries that I reported some time ago and should be fixed in the XFree 4.4 (or 4.5) release of the library part of the DRI.
What are you referring to by "4.4 (or 4.5)"? XFree86 4.4.0 isn't out yet, so I'm assuming you do not mean XFree86.
For that, could you send me the output of your 'glxinfo' ?
---snip--- name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Gareth Hughes, Leif Delgass, José Fonseca OpenGL renderer string: Mesa DRI Mach64 20020227 [Rage Pro] x86/MMX OpenGL version string: 1.2 Mesa 4.0.3 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow ---snip---
As you can see, it is reporting GLX version 1.2. However, <GL/glx.h> on my system mentions something about GLX 1.4. Go figure...
So, what is the fix to this problem? It would be trivial to have process_attach (in $(TOPDIR)/dlls/opengl32/wgl.c) to call wine_dlsym() for "glXGetProcAddressARB" without checking whether it is listed as an extension or not and to then check whether an error occured.
BTW, I think I have just found a potential (though unlikely) problem with the code in wglGetProcAddress. It checks whether p_glXGetProcAddressARB (the return value of wine_dlsym) != NULL. However, according to dlsym(3), the value of a symbol may be NULL.
Daniel
What are you referring to by "4.4 (or 4.5)"? XFree86 4.4.0 isn't out yet, so I'm assuming you do not mean XFree86.
Well, I did not follow at all XFree's development cycle lately. I was told that the next major XFree tree would have this fixed. So it must be 4.4.0 :-)
server glx vendor string: SGI server glx version string: 1.2
Well, so you are using GLX 1.2 and not 1.4 as Raphael told :-) At least, Wine checks only the runtime version, NOT the built-in versions.
So, what is the fix to this problem? It would be trivial to have process_attach (in $(TOPDIR)/dlls/opengl32/wgl.c) to call wine_dlsym() for "glXGetProcAddressARB" without checking whether it is listed as an extension or not and to then check whether an error occured.
Yeah, the fix is simply to remove the extension check (which was the code before I had a fit of spec correctiveness :-) ).
BTW, I think I have just found a potential (though unlikely) problem with the code in wglGetProcAddress. It checks whether p_glXGetProcAddressARB (the return value of wine_dlsym) != NULL. However, according to dlsym(3), the value of a symbol may be NULL.
Well, if a symbol value is 'NULL', I won't be able to call it anyway, no ? So it's exactly the same for me as a symbol that is not defined :-)
Lionel
-
Daniel Skorka -
Lionel Ulmer -
Raphaël Junqueira