[Xcb] XKEYBOARD protocol definition

[Peter Harris]

Eamon Walsh wrote:
> Some review below.  I haven't seen the earlier work so this will be
> zero-based.

Thanks! This is a great help.

> There are some changes upstream that aren't in your repo.  I needed to
> pull from xcb/proto to get recent changes.

Of course. You were looking at the "messy history" version that builds
upon the GSOC tree. That's my fault. I think I wasn't quite clear enough
in my proposal.

For what I'm actually planning to commit, please see
git://anongit.freedesktop.org/~peterh/xkbproto proposed
(ie the proposed branch), which I've just created. I will be rewriting
this branch frequently, so you probably don't want to base anything on
top of it.

The master branch will continue to contain incremental commits, if
that's easier for somebody to review.

> Obligatory whitespace comments: the indentation of the XML files is a
> little erratic.  There is some flagged whitespace I can see with git
> diff --color, some of which I mention below but not all.

Fixed. Thanks.

> +<switch name="identifier"> switch expression <bitcase> bitcase expression, fields </bitcase>
> +...</switch>
> +
> +  This element represents conditional inclusion of fields. It can be viewed as
> +  sequence of multiple if's: if ( switch expression & bitcase
> +  expression ) is equal to bitcase expression, bitcase fields are included in structure.
> +  It can be used only as the last field of structure.
> +
> 
> I don't see any new xcbgen Python code to handle this new element.  The
> only Python changes I see are to expr.py, adding new list length
> calculators.  Are there additional Python changes forthcoming, perhaps
> in the libxcb changes?

Quite the reverse. I don't plan to commit any python changes.

My arm could possibly be twisted far enough[1] that I'd look at libxcb
(and python code in general), but I haven't done that yet.

> +<replyof request="identifier" name="identifier" />
> +
> +  This element makes reply of request a field of structure.
> 
> This does not appear anywhere else and should be removed.

Done.

> +<enumref ref="identifier">enum item identifier</enumref>
> +
> +  This elements represents reference to item of enum.
> 
> s/elements/element/

Done (along with a number of other grammatical, style, and word-wrap
issues).

> +<sumof ref="identifier" />
> +
> +   This element represents sumation of elements of referenced list.
> +
> +<popcount>expression</popcount>
> +
> +   This element represents number of bits set.
> 
> 
> Going off on a tangent here: if popcount goes in, then we don't need the
> <valueparam> element in the schema anymore.  The reason is that the
> following two snippets are identical:
> 
> <valueparam value-mask-type="CARD32"
>             value-mask-name="value-mask"
>             value-list-name="value-list" />
> 
> <field type="CARD32" name="value-mask" />
> <list name="value-list" type="CARD32">
>   <popcount><fieldref>value-mask</fieldref></popcount>
> </list>

All true. Even better would be to use
<switch>(<bitcase></bitcase)+</switch> to replace valueparam, to allow
generation of code that replaces xcb/util/aux.

> diff --git a/src/xcb.xsd b/src/xcb.xsd

> +  <!-- Alignment = pad(expr) -->
> +  <xsd:element name="align" />
> 
> This appears to be unused in the XML and should be removed.

Done.

> diff --git a/src/xinput2.xml b/src/xinput2.xml

Not XKEYBOARD. I have not yet reviewed xinput2, nor do I intend to check
it in. Thanks for looking, though. I will keep this handy for when I do
get around to xinput2.

> Tangent: we will probably need some utility functions to convert these
> to floats and vice versa.

The same utility functions could be used for RENDER's fixed point
values, too.

> /me looks at the size of the xkb.xml file and decides to skip the rest
> of the XML for now.  Will do some more review when the libxcb stuff
> comes out and I can compile it.

That... could take a while.

Thanks again for the review.

Peter Harris

[1] I haven't spent enough time with python to really be comfortable
with it yet. Every time I look at python, it either feels like perl with
most of the expressiveness taken away, or lua with piles of cruft heaped
on top. It could be worse, though. It could be C...
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://connectivity.opentext.com/
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866