[PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

[Jesse Barnes]

On Thu, 05 May 2011 13:36:40 -0700
Jeremy Huddleston <jeremyhu at apple.com> wrote:

> >> Yes, I realize that there are some areas that use 64bit for sbc.  Do we really need 64bits for this?  If so, how do we properly to communicate the 64bit value between server/client?  Currently, your changes result in an implicit cast from 64bit to 32bits in DRI2SwapComplete which will cause problems if we really do need those extra bits:
> >> 
> >>    if (swap_complete)
> >>        swap_complete(client, swap_data, type, ust, frame, pPriv->swap_count);
> >> 
> >> It looks to me like much more of DRI2 should be rewritten to use 32bit swap counts, or there should be some other mechanism in place to communicate the full 64bit value.
> > 
> > Yeah there are other mechanisms (the OML sync extension) for
> > communicating the whole 64 bits.  Both the swap reply and msc reply
> > deal in the full 64 bits, just the swap event (an unrelated extension)
> > truncates to 32 bits.  (Also I think the 64 bit size for swap count in
> > the OML extension is just inertia; getting to a count that high even at
> > 120Hz is going to take awhile.)
> 
> Ok, well this all really doesn't sit well with me, but it would put my mind slightly at ease if you would do some logging of the problem if we encounter it in DRI2SwapComplete.  That might give your future self some clue as to what is going wrong when you see issues down the road:
> 
>    if (swap_complete) {
>        if (pPriv->swap_count > 0xffffffff)
>            ErrorF("something appropriate");
>        swap_complete(client, swap_data, type, ust, frame, (CARD32)pPriv->swap_count);
>    }

Yeah, it's annoying.  How about I leave out the error message and handle
wrapping on the client side instead?  That way at least the client code
won't notice that the server is only transmitting 32 bits...

-- 
Jesse Barnes, Intel Open Source Technology Center