[Xcb] New libxcb and xcb-proto releases (code name: "Oh, shit")

Uli Schlachter psychon at znc.in
Thu Nov 14 12:22:09 PST 2013

On 14.11.2013 21:02, Julien Cristau wrote:
> On Thu, Nov 14, 2013 at 18:52:22 +0100, Uli Schlachter wrote:
>> After the release:
>> - xcb-proto master:
>>   - revert GE introduction (cherry-pick from release?)
>> - libxcb master:
>>   - revert GE removal (cherry-pick from release?)
> I think defining GE in xcb-proto makes more sense than having it in
> libxcb, at least for 1.10.  Any chance you could be convinced to not
> revert these? :)

That's easy: Convince the code generator to generate the struct the way it was
defined in xcb.h.

However, the second byte in the struct was changed from "uint8_t pad0" to
"uint8_t extension". This is because of the xge="true" attribute on the <event>.
So we cannot mark this event as actually being a GE event and have to "fake" this.

This leads us to the following definition (this does generate the correct struct
(By the way, where does number="35" come from? This seems wrong as well. I just
shouldn't look at the XML in proto...)):

  <event name="ge" number="35">
    <field type="CARD8" name="pad0" />
    <field type="CARD32" name="length" />
    <field type="CARD16" name="event_type" />
    <field type="CARD16" name="pad1" />
    <list type="CARD32"  name="pad" ><value>5</value></list>
    <field type="CARD32" name="full_sequence" />

However, full_sequence is not actually on the wire and is just introduced by
libxcb, so this definition is wrong.

In other words:

I don't care if this definition lives in proto or xcb.h, but I won't try to move
it around and I don't think that this is an easy task.

And yes, short-term I will just revert those commits unless someone comes up
with a nice solution that does not break API. Feel free to revert the revert
when you do.

"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.

More information about the Xcb mailing list