Wow, that was fast. OK, what's the procedure for getting the fix? Do you suggest I wait for the next major X release, or try to pull and build from cvs, or apply a patch from you, or . . . ?
-'f On Sat, Apr 27, 2002 at 01:07:01PM -0600, Brian Paul wrote: > Brian Paul wrote: > > > > Geoffrey Broadwell wrote: > > > > > > Unfortunately, I've had no luck with this problem in any of the XFree86 > > > places I've tried (the newbie and xpert mailing lists, as well as > > > #xfree86), but I did get a response to try my question here. So here > > > goes: > > > > > > I'm trying to get Perl's OpenGL support working on my systems, which do > > > not currently have hardware acceleration support under Mesa. However, > > > Perl's OpenGL support requires an RGBA visual, > > > > Perl shouldn't require an alpha channel. The OpenGL spec says they're > > optional. But anyway... > > > > > but for some reason the > > > visuals available under software Mesa (the one builtin to XFree 4.1) are > > > all RGB-only for me. > > > > > > I've hit the same problem on both a laptop and a desktop, both installed > > > recently with Debian Woody, and both running the 4.1.0-16 X packages. > > > The XF86Config-4 files were both built using the debconf magic in the > > > X packages. Both are running at 1024x768, 24-bit color, with 4MB RAM. > > > The systems both have lots of system memory available, 128MB on one, and > > > 256MB on the other. Attached are the output of xdpyinfo and glxinfo; let > > > me know if you need the contents of the XF86Config-4 and/or XFree86.0.log > > > files. > > > > > > Anyone have any clue what's going on? As far as I can interpret the tea > > > leaves in the X log, it looks like I'm really running with 32-bit pixels, > > > so I don't see a problem there, assuming that for some reason Mesa was > > > fixing its internal pixel format to X's. > > > > The file that needs attention is xc/programs/Xserver/GL/mesa/src/X/xf86glx.c. > > That's where a set of default GLX visuals are defined for the case in > > which we don't have a DRI hardware accelerated driver. > > > > If you feel adventurous and want to compile a new GLX module you could > > try editing that file and adding a GLX visual with an alpha channel. > > > > Otherwise, I'll try to fix this for a future release since it would be > > useful to have a visual with alpha. > > > > Another work-around would be to use stand-alone Mesa (which builds a libGL > > that knows nothing about the X server's GLX) since it supports visuals with > > alpha channels. glxinfo won't report a visual with alpha but if you > > request it with glXChooseVisual() you'll get it. (long story) > > > I've changed xf86glx.c so that there's now a GLX visual with an alpha > channel. It's always 8 bits deep even if the RGB depths are 5/6/5 or > 3/3/2 since it's allocated by Mesa with a malloc'd buffer, not part of > the actual framebuffer. > > -Brian > > _______________________________________________ > Mesa3d-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
