[Xcb] GSoC proposal questions

[Mariusz Ceier]

Peter Harris pisze:
> 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?
> 
No, I don't have, and I don't think there is any. I only know that it
should be ready before I will need it (~28th July). I sent mail to
Daniel Stone, to get current status of Xkb2, but didn't get answer ( I
think that's because it could be to early to say anything about Xkb2 ).

>> 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".
> 
So trying to implement it can give me in-depth knowledge of XCB ( e.g.
what can be done easily and not in XCB ), sounds great :) But I must
warn that this is not my primary goal, so it may end up being unusable,
or incomplete.

>>> 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.
> 
ok, I will have a look ...

> 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. 
Yes I am already aware of this, but to know how this mechanism should
look like, I think I should know where and how could it be used ( what
are the requirements, use cases, etc. ).

> 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


Mariusz Ceier