[Xcb] GSoC proposal questions

Peter Harris git at peter.is-a-geek.org
Wed Apr 1 18:19:37 PDT 2009

On Wed, Apr 1, 2009 at 8:15 PM, Zephaniah E. Hull wrote:
> On Wed, Apr 01, 2009 at 05:16:34PM -0700, Barton C Massey wrote:
>> We'll dig you up a mentor, so you really don't have to.
>> Hopefully we can talk Peter into dealing with the hard part
>> of it, i.e. the input side, and any of us can help mentor
>> the XCB part.  I don't think you need to know any XCB
>> internals; just be able to write protocol descriptions in it
>> and build libraries atop it as far as I can tell.
> Can the code generators actually handle some of the, unique aspects of
> the input protocols?
> IIRC, when I last looked at this (about a year and a half ago) there
> were some challenges involving how XInput and friends put things on the
> wire.

Just off the top of my head, XInput 2 needs Generic Event support. If
I understand correctly, XGE is going to be used for essentially all
future extensions, so XCB is going to have to grow support for it
sooner or later. Sooner is better, in my opinion.

In terms of some of the other quirks, we can either improve the code
generator, or we can punt. xcb/util is not a bad place to put
hand-written helper functions to deal with the most unique bits.

There are already places where XCB punts (GetProperty/SetProperty
doesn't have a way to specify the unit size of the data, and
RANDR/Notify doesn't have a way to specify which of the union members
is referenced, to pick two off the top of my head. The RANDR/Notify
thing in particular doesn't look too dissimilar from the gaps in the
current xinput.xml protocol description. With a little care, the
solution for one could probably be applied to the other.)

Peter Harris

More information about the Xcb mailing list