On Wed, 2009-01-21 at 16:46 +0100, Michel Dänzer wrote: > If the decoration drawables had depth 24, it should be the same issue > with DRI1, but that's been working fine for me for the last two years or > so.
I did end up following that reasoning myself.. so will have to dig deeper at just what drawable is used for the decoration, and how that aspect of compiz works. If it is modifying the texture before drawing it, that might explain the problem (since I'm triggering a different texturing operation for textures mapped from 24bit depth windows. On the other hand, that doesn't really stack up with the idea that these operations are zero-copy. > Probably the 3D driver setTexBuffer hook needs to make a similar texture > format override depending on the drawable depth. That sounds like a fun foray into 3D driver hacking.. if I get some time, I'll see how I can make it work *. *(Not to let that stop someone who knows the code-base getting there first!.. the code is very abstracted, so will take a bit of getting my head around). > I'll defer your other questions to Kristian Høgsberg, who wrote most of > the DRI2 code so far. Sure. Guys.. any idea if the setTexBuffer hook has enough information to know what format the underlying Pixbuf is going to be in? Does simply setting: type = rb->base._BaseFormat; Stand any chance of working? (Compiling now ... ... ... ... -> coffee time) -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
