[RFC] DRI2 synchronization and swap bits

[Jesse Barnes]

I've put up some trees (after learning my lesson about working in the
main tree) with the latest DRI2 sync/swap bits:
  git://git.freedesktop.org/home/jbarnes/xserver master branch
  git://git.freedesktop.org/home/jbarnes/mesa master branch

They includes support for some new DRI2 requests (proto for which is in
the dri2-swapbuffers branch of dri2proto), including:
  DRI2SwapBuffers
  DRI2GetMSC
  DRI2WaitMSC
and
  DRI2WaitSBC

These allow us to support GLX extensions like SGI_video_sync,
OML_swap_control and SGI_swap_interval.

There have been a few comments about the protocol so far:
  1) DRI2SwapBuffers
     a) Concern about doing another round trip to fetch new buffers
	following the swap.
        I think this is a valid concern, we could potentially respond
        from the swap with the new buffers, but this would make some
        memory saving optimizations more difficult (e.g. freeing
        buffers if no drawing comes in for a short time after the swap).
  2) DRI2WaitMSC/SBC
     a) Concern about blocking the client on the server side as opposed
        to a client side wait.
        I'm a bit less worried about this, since these type of waits
        typically aren't very latency sensitive.  Doing the wait on the
        client side is definitely possible though if really desired,
        though it would split the request for the DRM event and its
        consumption across the server/client boundary (we'd have to
        return the sequence number to look for to the client, then
        have it poll the DRM fd).

The implementation tries to avoid blocking the clients at all for swap
requests, only blocking them on wait requests that are specified to
cause blocking.  This should allay the concerns raised in the page
flipping thread about unnecessary blocking of clients (that's left as
an implementation detail for the drivers supporting these new
functions).

As mentioned above, these changes require new dri2proto, but they also
need libdrm master and airlied's drm-next branch, which has the vblank
event bits that the new server code depends on.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center