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

[Uli Schlachter]

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" />
  </event>

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.

Uli
-- 
"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.