[Xcb] xinput2 - request for help and comments
Christoph Reimann
chrr at arcor.de
Mon Nov 12 09:52:49 PST 2012
Hi, just read this comment while browsing through the archive - while
I have no solution at hand, I can offer an explanation.
I wrote this to the mailing list >2 years ago:
"
It is not trivially possible to get the size of a switch byte stream. One
could use the _sizeof() function of course, but in order to evaluate switch,
always additional parameters have to be supplied (keep in mind that switch
stands for conditional inclusion of fields). These additional parameters do
not fit within the existing interface for iterators. However at the moment
it is not necessary to have iterators for switch, as no lists of switch
statements exist in the spec. Accessors should be working without further
modifications, however there are no accessors for switch fields as these as
well would require additional parameters.
"
So in order to get a LIST of CLASSES of SWITCH, additional _sizeof()
functions are needed - not trivial.
I think the changes to the python script should be simple once the
logic has been worked out.
As far as I remember there were more issues with switch etc., I have
noted them down somewhere/will repost them as soon as I find my notes.
Christoph
On 5 November 2012 20:25, Daniel Martin <consume.noise at gmail.com> wrote:
> Hi everyone,
>
> I'm working on bringing xinput2 support to xcb and I need a helping hand
> and one or the other suggestion.
>
> Lots of things are straight forward, but the reply of the QueryDevice
> request is very complex and can't be processed with the current
> implementation of xcbgen.
>
> QueryDevice in the spec:
> http://cgit.freedesktop.org/xorg/proto/inputproto/tree/specs/XI2proto.txt#n684
>
> Besides a CARD16, this reply contains a LISTofDEVICEINFO, which contains
> a LISTofCLASS. Each CLASS can be of a different type with a different
> (even variable) length.
>
> To give you a hint on what I think the xml implementation should look
> like, I've prepared and attached a stripped to the bones examples.
> Summary for this example:
> - the reply has a "list of DeviceInfo structs"
> - a DeviceInfo struct has a "list of ClassInfo structs"
> - a ClassInfo struct has the default header (type, length, sourceid) and
> a switch for the different types to represent their details
>
> That switch inside of the struct can't be handled atm. and xcbgen
> complains about it with:
> Traceback (most recent call last):
> File "./c_client.py", line 2925, in <module>
> module.generate()
> File "8< to long 8< /state.py", line 101, in generate
> item.out(name)
> File "./c_client.py", line 1818, in c_struct
> _c_iterator(self, name)
> File "./c_client.py", line 1333, in _c_iterator
> _c(' xcb_generic_iterator_t child = %s;', \
> _c_iterator_get_end(self.last_varsized_field, 'R'))
> File "./c_client.py", line 1270, in _c_iterator_get_end
> return _c_iterator_get_end(field.type.last_varsized_field, accum)
> AttributeError: 'SwitchType' object has no attribute \
> 'last_varsized_field'
>
> Additionally, I've added a <case> element into the schema, patch is
> attached as well. Haven't made it a "real git" patch, cause it's a rfc.
> The (class) types (Key=0, Button=1, Valuator=2, Scroll=3, Touch=8) are
> constants, not bitfields, so this might be necessary.
>
> I've already had a working example without such a switch. But, in that
> example one would have had to walk through the LISTofDEVICEINFO and
> LISTofCLASS by hand and that's definitly something for an iterator.
>
> I appreciate any suggestions, much more if it simplifies something. Or
> if you're more skilled in Python than I'm, which is not difficult, and
> could try to enhance xcbgen the way which is necessary to solve this
> issue, that would be fantastic, too.
>
> Thanks to Peter Harris and Peter Hutterer who answered my questions so
> far.
>
>
> Cheers,
> Daniel Martin
>
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
More information about the Xcb
mailing list