On Wed, 2006-06-21 at 11:41 +0200, Martijn van Oosterhout wrote: > On 6/21/06, Michel Dänzer <[EMAIL PROTECTED]> wrote: > > The X server defines them, but with direct rendering, it's the client > > driver's responsibility to actually apply them to the hardware. > > <snip> > > > This should never happen because the Mesa driver should check for > > cliprect updates and apply them every time it acquires the hardware > > lock. It sounds like the r128 driver is failing to do that, or maybe it > > doesn't hold the hardware lock for all rendering. > > But the client receives the updates via an X protocol message, right? > So if a program ignores events long enough, it could scribble over > anything.
There's no event involved. The driver sends a request and waits for the reply synchronously. I'm not aware of any circumstances where this wouldn't work as intended. > Anyway, closer investigation reveals the issue to be somewhat more > complex. Even after you've got an overlapping window and the clipping > is apparently set correctly, sometimes drawing bleeds through. > Sometimes individual pixels, sometimes whole polygons. It's like some > drawing operations are being exempted from the clipping check. That > doesn't seem possible though. > > OTOH, reading through the driver code in the X server, is seems the > card may not support arbitrary clipping rectangles in hardware, so > maybe theres a bug in the software clipping code. Oh well, it's > something to go on. That might explain why only overlapping windows > are a problem. Sounds like you're closing in on the problem. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
