[Xcb] GSoC 2010 - Improving input support

Christoph Reimann chrr at arcor.de
Wed May 26 14:07:50 PDT 2010

Dear list members,
I just noticed that I unfortunately did not announce officially to the
list (but only to a few people in private to whom I was in contact
earlier) that I got the XCB GSoC this year . Please excuse the delay,
I was quite busy the last 3 weeks getting up-to-date with XKB
documentation and XCB APIs.
I am currently working on extending the python generator code to cope
with the newly introduced tags by Mariusz Ceier last year. I will post
details and (preliminary) suggestions for a C language mapping in the
next few days.

Currently one thing is unclear to me: In order to evaluate the bitmask
for a <valueparam>, the value-mask-type should be taken into account.
I will try to formulate my questions clearly first:
1. Are these bitmask types constrained to not exceed CARD32 (I think
not from reading xproto)?
2. If not - is it safe to assume they will not exceed CARD32 anyway?
In the C code generator (c_client.py) it appears that uint32_t is
implicitly assumed:
l. 465     elif expr.bitfield:
                   return 'xcb_popcount(' + lenexp + ')'
The function xcb_popcount is defined in xcbext.h as int xcb_popcount
(uint32_t mask);
so the lenexp argument is automatically casted to uint32_t. Now that
might not be an issue as the value-mask-type is set to CARD32 in all
cases I looked at - still I would like to know if this behaviour is
wanted. Also I would like to use xcb_popcount() to resolve the newly
introduced <popcount> tag.

Thanks in advance for answers :)
I will keep you informed of my progress (X.org also wants me to blog
about it, I will send you the link in the next few days),


More information about the Xcb mailing list