Initial DRI3000 protocol specs available

[Keith Packard]

Owen Taylor <otaylor at redhat.com> writes:

> A complex scheme where the compositor and the server collaborate on the
> implementation of SwapRegion seems fragile to me, and still doesn't get
> some details right - like the swap count returned from SwapRegion.

The question is whether the SwapCount is the count of swaps on the
window, or the count of swaps to the final screen image. I think it's
just the former, in which case the presence of a compositor doesn't have
any effect on the correctness.

The effect of the compositor is strictly in holding a reference to the
window buffer and potentially delaying the reuse of that buffer within
the application.

> What if we made SwapRegion redirectable along the lines of
> ResizeRedirectMask? Since it would be tricky to block the client calling
> SwapRegion until the compositor responded, this would probably require
> removing the reply to SwapRegion and sending everything needed back in
> events. At the most granular, this would be:

We're really trying to avoid using events here -- they're quite messy on
the client side as you must capture them deep within the X library
implementation and shovel them over to the correct context within the
Mesa library. Using replies makes it all quite simple; the correct
context will be present automatically to receive the reply from SwapRegion.

>  * Not leaking buffers during redirection/unredirection could be tricky.
>    What if the compositor exits while a client is waiting for a
>    SwapIdle? An event when swap is redirected/unredirected is probably
>    necessary.

With the current pixmap ID referencing technique, that ID will be freed
when the compositor exits (I mentioned this would be required before)
which will reduce the reference count to the point where the SwapIdle
event would get sent.

> Is this better than a more collaborative approach where the server and
> compositor together determine what pixmaps are idle? I think it might be
> a little simpler and more flexible. It also potentially allows a
> SwapRegion on a client window to be directly turned to a SwapRegion on
> the root window for a full-screen client. But there probably are a host
> of difficulties I'm not thinking of :-)

Oh. Having the compositor just take the new window buffer and send a
SwapRegion from that to the root window. I hadn't thought of that, as
I was still assuming we'd be 'unredirecting' full screen windows, but
this sure looks like a compelling alternative plan that should simplify
the compositor fairly nicely.

Let's stick that one on the list of 'it sure would be nice if this were
possible' list and see what it will take to make it work.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130226/29e4c8e8/attachment.pgp>