[Xcb] xinput: up to XI v2.3 with all events

[Jamey Sharp]

On Sun, Feb 17, 2013 at 01:26:44AM +0100, Daniel Martin wrote:
> The field gets injected there cause I told xcbgen to do so in my XGE
> patch. Which is definitly wrong!
> And moving it to the beginning raises other problems. Howto hand
> out the structure to clients?
> - There may be clients relying on the byte order of events, which don't
>   expect the full_sequence field there and therefor interpreting
>   garbage.
> - Or if we would hand out the structure with the offset (pointer behind
>   full_sequence field) they can't free() the reply anymore and the
>   field would be hidden.
> 
> Meanwhile I've found a bug report from Jamey, created in 2006:
>     Errors and events should include their 32-bit sequence number
>     https://bugs.freedesktop.org/show_bug.cgi?id=6105
> I'll pick it up. Because I think there're 2 open points in it and
> resolving them would nearly solve my problem with the XGE events vs.
> full_sequence field.

I always meant to do something about that. Thanks for looking into it!

For the C API, my best plan was to add new API functions for getting
events, where the function signature included an out-parameter for a
larger sequence number. If you don't care about the sequence number then
you'd pass a null pointer.

If you use this new API, then the structure you get back would exactly
match the bytes read off the wire--events and errors read this way
wouldn't have a magic full_sequence field. (I'm not sure what to do for
type-safety issues if there are effectively two types of
xcb_generic_event structures floating around...)

A few years after filing bug #6105, I made XCB use 64-bit sequence
numbers everywhere internally. So new API fixing these issues should
expose 64-bit sequence numbers to callers. (People often regret making
this kind of claim but) 64 bits ought to be enough for anybody.

As an implementation detail, I suggest adding a 64-bit sequence number
to struct event_list in xcb_in.c, and quit inserting full_sequence
during read_packet. For compatibility, the existing xcb_wait_for_event
and xcb_poll_for_event functions need to insert the full_sequence field
for existing callers.

Note that replies don't need the same things, because the caller asks
for a reply with a given sequence number--so the caller already has as
many bits of the sequence number as they want. Now, ideally we'd offer
64-bit versions of reply cookies and a 64-bit xcb_wait_for_reply, but I
think that's a trickier API design problem, and I'd suggest not worrying
about it.

I don't have time to implement this, but I'd be delighted to review a
patch for it!

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20130217/69da3749/attachment.pgp>