[Xcb] [RFC libxcb 0/5] Fix GE events from the ground up, leading to a full 64bit sequence API

[Josh Triplett]

On Wed, Jun 05, 2013 at 12:52:01AM +0200, Daniel Martin wrote:
> we need to fix GE events to be able to support extensions using such
> events properly. Atm. xcb_ge_event_t has the full_sequence field at the
> 32byte boundary, where it's not supposed to be, because GE events can be
> larger then 32byte.
[...]
> A summary of the visible (API) changes:
> - Removed the full_sequence from
>     xcb_generic_event_t,
>     xcb_ge_event_t and
>     xcb_generic_error_t.
> - Added a function to be able to get the sequence, which has a parameter
>   to adjust its behavior (wait, poll or just watch the queue for
>   events):
>     xcb_rcv_event()
> On top of that I additionally changed the remaining "sequences". That
> means:
> - Made cookies have uint64_t sequences
> - Changed all sequence parameters to uint64_t. Most of those functions
>   aren't "that" public. They're wrapped in the specific request/reply
>   functions. And the change usually was: changing an 'in' parameter from
>   unsigned int to uint64_t, which shouldn't be a big deal if you would
>   still pass an unsigned int.
> With that, libxcb uses uint64_t for sequences from the beginning to the
> end. (No widen() is necessary anymore.)

I'm all for this change; it makes much more sense for xcb to return the
64-bit sequence numbers out-of-band rather than shoehorning it into what
should be wire-format structures.

However, I'd propose doing this in two steps.  First, add a new set of
functions and structures that follow the pattern described above,
leaving the existing ones in place, and deprecate the old ones.  Second,
remove those functions and bump the SONAME.  The first of those two
changes should be uncontroversial; we can then argue over when (or if)
we should do the latter without delaying the former.

- Josh Triplett