[Xcb] [RFC v0 proto] Add XInput2 protocol description

Daniel Martin consume.noise at gmail.com
Mon Dec 3 23:30:53 PST 2012

On Mon, Dec 03, 2012 at 04:21:35PM -0500, Peter Harris wrote:
> On 2012-12-03 16:05, Daniel Martin wrote:
> > (In the following I'll write "XI2" when I mean the XInput extension
> > starting with version 2.0 and "XI" for the version up to 1.5.)
> > 
> > On Mon, Dec 03, 2012 at 09:56:26AM -0500, Peter Harris wrote:
> >> On 2012-12-02 16:05, Daniel Martin wrote:
> >>> Add the XInput2 protocol description for reviewing and feedback.
> >>
> >> I haven't had time to review the meat of this, but this stuck out on an
> >> initial glance:
> >>
> >>> +	xinput2.xml \
> >>
> >>> +<xcb header="xinput2" extension-name="Input2"
> >>> +     extension-xname="XInputExtension" major-version="2" minor-version="2">
> >>
> >> That's the same extension-xname as xinput.xml. I suspect the new
> >> definitions should be in xinput.xml, not in their own file.
> > 
> > I've choosen to make it in a seperate file, cause the extension name is
> > nearly the only thing both versions have in common and XI2 superseeds
> > the functionallity provided by XI.
> Except for the QueryVersion request, which is only present in the XI1
> description. I suppose it could be duplicated in xinput2.xml, but see below.
> > Supporting both versions is not necessary as the XI specification
> > states:
> >     "... New clients are discouraged from using this protocol
> >          specification. Instead, the use of XI 2.x is recommended. ..."
> > 
> > Mixing both versions in one file would cause to much confusions on the
> > (library) user side, as he wouldn't know which request is for which
> > version without having a look at the specification.
> > 
> > Due to that, the fact that the protocol description for XI is not
> > complete and XI is disabled by default in libXCB, I would rather mark it
> > as deprecated when this XI2 protocol description becomes usable. But, I
> > wouldn't like to merge them.
> Be that as it may for libxcb, the Wireshark dissector generator is not
> expecting to find the same extension spread out over multiple files.
> If we deprecate xinput.xml, we can move QueryVersion into xinput2.xml.
> But that leaves Wireshark without support for older (XI1) clients.
> I'd generally prefer to keep the special cases to a minimum, but it's
> not all that much work to add extension merging (especially if you don't
> duplicate any requests) to the Wireshark generator. Before I do that,
> I'd like to hear if anybody else has an opinion on this topic.

Looks like my point of view was way to much aligned on libxcb. As we
have those generic protocol descriptions in XML, it should be as easy as
possible for everyone to make whatever he wants to do with it. Without
adding special cases.

And for libxcb (not only) users, I could add statements in the <doc>
tags to mark XI1 stuff. Cause having such information in the
documentation should be enough - I must admit.

More information about the Xcb mailing list