Re: [Dri-devel] Re: Another question on Fedora GL
Either that or apps can work around buggy libGLs by checking the client extension string for GLX_ARB_get_proc_address. That extension is client-side only, so that's good enough. Well, this is the output of a glxinfo from an user with the bug : 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 And you can see that no extension string (wether client, server or GLX) reports any 'get_proc_address' extension. Lionel -- Lionel Ulmer - http://www.bbrox.org/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Another question on Fedora GL
Lionel Ulmer wrote: Either that or apps can work around buggy libGLs by checking the client extension string for GLX_ARB_get_proc_address. That extension is client-side only, so that's good enough. Well, this is the output of a glxinfo from an user with the bug : [snip] And you can see that no extension string (wether client, server or GLX) reports any 'get_proc_address' extension. That's right. I had forgotten that the old libGL was that broken. Sorry. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Another question on Fedora GL
I'd point you to the patches if I could remember when this last came up. If someone has time they might look through the dri-devel or dri-users archives. Does anyone on dri-devel remember this issue and what the fix was? glXGetProcAddressARB not being available. Alex --- Mike A. Harris [EMAIL PROTECTED] wrote: On Fri, 14 Nov 2003, Alex Deucher wrote: This was an issue with 4.3.0 as I recall. It was fixed in DRI cvs, I'm not sure if the fix has made it's way to fedora. I don't recall hearing about this issue before, so it probably isn't fixed in our packages unless it is fixed in XFree86's 4.3.0 stable branch xf-4_3-branch, as I track the branch. If someone out there is interested in seeing this fixed in a future Fedora Core XFree86 update digs the needed patches out and files a bug report in Red Hat bugzilla with patch attached, or sends them to XFree86.org to be included in xf-4_3-branch, I'd be glad to include them in an update though. Take care, TTYL --- Sergey V. Oudaltsov [EMAIL PROTECTED] wrote: Well, now all my GL libs look fine. But when I try to run Counter-Strike in OpenGL mode, I get this: err:opengl:wglGetProcAddress Warning : dynamic GL extension loading not supported by native GL library. On the web, I found this comment: This means that the glXGetProcAddressARB function seems not to be supported by your OpenGL library. But AFAIK Mesa libGL has this function. Any ideas why would it be lost in the battle by wine? Sorry if it not the right list to ask questions of that kind. In such case, private answers would be appreciated as well. -- Mike A. Harris ___ xfree86-list mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/xfree86-list IRC: #xfree86 on irc.redhat.com __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Another question on Fedora GL
On Fri, Nov 14, 2003 at 01:11:24PM -0800, Alex Deucher wrote: I'd point you to the patches if I could remember when this last came up. If someone has time they might look through the dri-devel or dri-users archives. Does anyone on dri-devel remember this issue and what the fix was? glXGetProcAddressARB not being available. Well, I am at least partially responsible for this problem Basically, I am extra-strict in the Wine OpenGL code when checking for the presence of the glXGetProcAddressARB call (ie I not only check for the presence of the symbol with dlopen / dlsym but also check for the presence of the 'GLX_ARB_get_proc_address' string in the GLX extension string reported by the server). When I last raised this issue on this list, I was told that the new DRI release would fix this and report this extension. I could look in my mailing list archives to see who told that and when :-) Anyway, if you have the Wine source tree, you have to only change one line to fix this issue :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/ --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Another question on Fedora GL
Lionel Ulmer wrote: On Fri, Nov 14, 2003 at 01:11:24PM -0800, Alex Deucher wrote: I'd point you to the patches if I could remember when this last came up. If someone has time they might look through the dri-devel or dri-users archives. Does anyone on dri-devel remember this issue and what the fix was? glXGetProcAddressARB not being available. Well, I am at least partially responsible for this problem Basically, I am extra-strict in the Wine OpenGL code when checking for the presence of the glXGetProcAddressARB call (ie I not only check for the presence of the symbol with dlopen / dlsym but also check for the presence of the 'GLX_ARB_get_proc_address' string in the GLX extension string reported by the server). When I last raised this issue on this list, I was told that the new DRI release would fix this and report this extension. I could look in my mailing list archives to see who told that and when :-) It was I that told you that. The fix is in the DRI tree and should be in the current XFree86 tree. I'm 99.9% sure that it will be in 4.4.0. Basically, the fix is a side-effect of the GLX extension tracking code that was added post-4.3.0. Since GLX_ARB_get_proc_address *is* always there, distros can patch 4.3.0 (and earlier) releases by just appending GLX_ARB_get_proc_address to the effectiveExtensions string stored in the __GLXscreenConfigsRec. Either that or apps can work around buggy libGLs by checking the client extension string for GLX_ARB_get_proc_address. That extension is client-side only, so that's good enough. My honest opinion is that both should be done. Anyway, if you have the Wine source tree, you have to only change one line to fix this issue :-) --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
