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

[Daniel Martin]

On Tue, Jun 04, 2013 at 04:42:56PM -0700, Keith Packard wrote:
> Daniel Martin <consume.noise at gmail.com> writes:
> 
> > Hi everyone,
> >
> > 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.
> >
> > The XInput extension v2++ uses GE events, so it's a show stopper on the
> > way to have a decent support for it.
> 
> For my DRI3 hacking, I did just stick the sequence number in the event
> encoding:
> 
>   <event name="ConfigureNotify" number="0">
>     <field type="CARD8" name="extension" />
>     <field type="CARD32" name="length" />
>     <field type="CARD16" name="evtype" enum="EventType" />
>     <pad bytes="2" />
>     <field type="EVENT" name="event" />
>     <field type="WINDOW" name="window" />
>     <field type="INT16" name="x" />
>     <field type="INT16" name="y" />
>     <field type="CARD16" name="width" />
>     <field type="CARD16" name="height" />
>     <field type="INT16" name="off_x" />
>     <field type="INT16" name="off_y" />
>     <field type="CARD32" name="full_sequence"/>
>     <field type="CARD16" name="pixmap_width" />
>     <field type="CARD16" name="pixmap_height" />
>     <field type="CARD32" name="pixmap_flags" />
>   </event>

That's something I thought about too. That brings a burden for everyone
not using libxcb, but using xcbgen or the xml specification directly. As
they would need to handle this libxcb specific field where they wouldn't
need to do.

You could use commit
    Add support for X Generic Extension events
    df548352c5f3440bdbf57cce8103c7e55e246261
from my github branch "rev-xinput" at
    github.com/bartsch/xcb-proto
until we handle GE events correctly. That way you don't need to add the
full_sequence yourself into the event structures.

> > One hack would be to inject the full_sequence into GE event structures
> > while generating the header files. But, that would expose the
> > full_sequence in specific events, somewhere in the middle of the usual
> > event data, which is not conform to any specification one can read about
> > this specific event.
> 
> I don't think that would matter much, and would retain ABI/API
> compatibility with the existing codebase. Certainly seems like the
> easiest plan to me.
> 
> > Additionally, this injection would need to happen
> > in c_client.py. Injecting it within xcbgen would force any user of
> > xcbgen to handle the mistake that happened in libxcb.
> 
> I looked at hacking up the c_client.py script to do this but gave up and
> just hacked my .xml file directly, which definitely didn't seem right.

Yeah, c_client.py is special. I gave up on it while trying to add
necessary features, too. But, that's another story and I've started to
fix it up in a local branch.

> > The commit messages may need some polishing. But, for now I would like
> > get some comments on this. As those changes break API and ABI I'm sure
> > there'll be some. ;)
> 
> I think I'd rather avoid the API/ABI breakage and just leave the
> full_sequence where it lives today; it's a bit ugly, but applications
> won't actually see it in source code.

But, they see it in the generated event structure.

I'll adopt the "2 step" suggestion of Josh. That won't be such a hard
change.


Thanks for your comments,
    Daniel