[Xcb] GSoC proposal questions

[Peter Harris]

Mariusz Ceier wrote:
> Peter Harris pisze:
>> 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.
>>
> So the better idea would be to implement XGE before Xi2,
> do you know if it is the same for any of Xkb,Xi,Xkb2 ?
> I think it is for Xkb2, a not Xkb,Xi, but I'm not sure.

Xkb and Xi were written before XGE, so they can't possibly depend on it.

I can't seem to find the spec for Xkb2 - do you have a link?

> It seems to be a small extension ([0,[1]), so it can be good to
> implement it during community bonding period, what do you think ?

It is a small extension, but to implement it you will have to touch
everything from xcb.xsd through c_client.py. So, yes, implementing XGE
would be an excellent way to "get your feet wet".

>> There are already places where XCB punts (GetProperty/SetProperty

(Oops. Should read GetProperty/ChangeProperty)

>> 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.)
> Ok, so should I read RANDR protocol description too ( or an excerpt from
> it, about Notify event ), or reading xrandr.xml will be sufficient ?

The important bit is right at the end of randr.xml.

The field "subCode" should indicate which of the structures contained
within the union "u" is used. This information is irrelevant for libxcb,
but will be needed if we ever do server side XCB[1].

The big problem with Xinput 1 as implemented in xinput.xml is "<!--
Uninterpreted: list of InputState structures -->". In order to interpret
InputState, you will need some mechanism for picking different
structures of different sizes. If the mechanism you create to solve this
is designed carefully, then this same mechanism could be applied to
randr/Notify. Also to xproto/ClientMessage and xproto/GetProperty.

I didn't intend to suggest that you expand your GSoC project to include
anything outside Xi/Xkb 1/2. I just mentioned it so you can keep it in
the back of your mind when designing some of the mechanisms you will
need to flesh out Xi support. Also to point out that xcb/proto isn't
perfect, so if you need to punt on some things (due to time or
complexity constraints) and fix it up in the xcb/util part of your
project, there is precedent.

Peter Harris

[1] ...and could also be useful for a Wireshark dissector:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2981
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://www.opentext.com/connectivity
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866