r300SetTexBuffer2 looks at the 'cpp' field of the radeon_renderbuffer to decide what radeon texture format (pp_txformat) to use. The cpp comes the dri2 getBuffers - (see radeon_common_context.c:radeon_update_renderbuffers()) and is 4 even for a depth-24 X server pixmap. I'll attach a patch that fixes the problem locally; it's definitely a safe fix since if the GLXPixmap was created with GLX_TEXTURE_FORMAT_EXT attribute of GLX_TEXTURE_FORMAT_RGB_EXT, it can only be bound to RGB textures and A should be fixed at 1. Is it the correct fix? As implemented in the Radeon DDX, the cpp value comes from drawable.bitsPerPixel, so is 32 for both xRGB and ARGB pixmaps. This seems reasonable (though the DRI2 spec doesn't define what cpp is!), so the patch is probably along the right lines as well - but may need some extension: - The cpp == 3 case then shouldn't occur, since it would reflect packed pixels, something that the hardware can't support. - The r100/r200 drivers have pretty much identical code paths that would need the same fix.
Created attachment 25580 [details] [review] Patch as described
Pushed along with a fixes for r1xx and r2xx. ea6a74abbe4053b958d640425e061f0ceec92291 7cd57e35b6427068b87c2fdb6c2aadef57f53520
does this bug fixed the rgba problem with dri2 and kde4/compiz/gtk? because i'm using the latest mesa from glisse (which has this patch) and i'm still having problem with wrong rgb colors with gtk and kde4 apps.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.