System: ABIT BP-6 dual Celeron/466 GPU: 3dfx Voodoo3 3000, PCI, 16MB OS: Stock Red Hat 7.1 (XFree 4.1)
Most everything works great out of the box. Quake3 runs smooth (30-40fps is plenty for me), and gears churns out about 500 fps. But good old Quake2 is just too dark. So, I tried the SSTH3_xGAMMA (x=R,G,B) environment variable Glide hack. I found the code that does the gamma table loading in /usr/src/redhat/BUILD/XFree86-4.1.0/Glide3/h3/minihwc/linhwc.c.dri (from the XFree86 SRPM) The function is hwcGammaTable(), which ends up living in /usr/lib/glide3/libglide3-v3.so It looks like it has mmapped access to the 3dfx regsiter space and sets the gamma tables via address/offset poking. I know it *works*, because I can see the whole screen go darker or lighter depending on the SST* env. settings, but only for a split-second, then it reverts to whatever it was before. I tried debugging a copy of gears, and I found that the gamma tables get reset in this code path in libglut, glutMainLoop() interruptibleXNextEvent() XFlush(__glutDisplay) The reset happens right at the XFlush(), so its as if the X Server is setting the gamma tables back to default values. All the SST* processing of course happens in the client app. So what I'm looking to do is track down where in the X server this might be happening, and I'm not sure where to look. Any pointers? Thanks, -Jamie p.s. I realize SSTH3_* is a hack, and Quake2 is probably slightly broken since it can't properly set brightness, but this is a fun little hack project to see if I can get it working. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
