ShadowFB + Composite + RandR + ?

Thomas Winischhofer thomas at
Wed Sep 28 10:33:25 PDT 2005

Hash: SHA1

Keith Packard wrote:
> On Tue, 2005-09-27 at 22:00 +0200, Thomas Winischhofer wrote:
>>Hash: SHA1
>>Sorry for this monologue:
>>Thomas Winischhofer wrote:
>>>PaintWindow and CopyArea and others (noticed especially PolyFillRect)
>>>are called even in case the composite manager has redirected a window.
>>This assumtion was correct: My wrapped functions were called even for
>>off-screen drawables. I have added a check if the drawable is the
>>frontbuffer now and this works like a charm. No illegal boxes any more.
> So do you believe there is a bug in the composite code, a misfeature of
> that code which drivers should work around, or a bug in your driver?

Well, it is no bug in composite, I would say. It is a problem with
composite in combination with shadowfb.

Composite does it job as it should: It renders stuff into offscreen memory.

I needed shadowfb as a "shadow *front* buffer", not "framebuffer" in
general, since I only rotate the front buffer. That's what shadowfb
obviously isn't meant to be.

And as I just found out, if I enable the shadowfb option (everything
else disabled, including 2D acceleration), X will crash as soon as the
composite manager is started. This should be easy to reproduce for
everybody, with any driver that supports shadowfb. And it will
especially affect the sisusb driver as it depends on shadowfb.

So I think it is a bug in shadowfb: Shadowfb must only hand boxes to the
refresh handler, if the destination drawable is the frontbuffer (the
root window).

Unfortunately I have absolutely no time to fix this now. Any volunteers?


- --
Thomas Winischhofer
thomas AT winischhofer DOT net	       ***

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the xorg mailing list