Initial DRI3000 protocol specs available

[Owen Taylor]

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.

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:

 SwapScheduled - whatever information is available immediately on
                 receipt of SwapRegion
 SwapIdle      - a buffer is returned to the application for rendering
 SwapComplete  - the swap actually happened and we know the
                 msc/sbc/ust triple

But I don't know that you need that much granularity. I think SwapIdle
and SwapComplete are sufficient.

Tricky parts:

 * 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.

 * To make this somewhat safe, the concept of "idle" has to be one of
   correct display not system stability. It can't take down the system
   if the compositor sends SwapIdle at the wrong time.

 * Because the SBC is a drawable attribute it's a little complex to
   continue having the right value over swap redirection.

    When a window is swap-redirected, we say that the SBC is
    incremented by one every time the redirecting client calls
    SwapRegion, and never otherwise. A query is provided for the
    current value.

 * It doesn't make sense to have both the server and the compositor
   scheduling stuff. I think you'd specify that once you swap
   redirect a window, it gets simple:

   - SwapRegion called by another client - SwapRegionRequest is
     immediately generated.
   - SwapRegion called by redirecting client - action (either a
     swap or a copy) happens immediately.

   Actually, from the compositor's perspective, the window's front
   buffer doesn't matter, but you probably need to keep it current
   to make screenshot tools, etc, work correctly.

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 :-)

- Owen