First XI2 server implementation

[Peter Hutterer]

On Thu, Apr 23, 2009 at 12:49:05AM -0400, Eamon Walsh wrote:
> Peter Hutterer wrote:
> > The current protocol specification is in inputproto/XI2proto.txt and in most
> > places identical to 
> > http://lists.freedesktop.org/archives/xorg/2009-February/043510.html
> > Notable differences:
> >   - raw events do not include button state
> >   - FP1616 type implemented as INT16.CARD16
> >   - Enter/leave events include button/modifier state
> >   - Focus events added - basically identical to enter/leave events.
> >   
> 
> Are you planning to duplicate the ListInputDevices wire encoding with
> the new QueryInputDevice?  The ordering on the wire is not the same as
> in the protocol spec; all the  BUTTONCLASS etc. are in one big list
> after the DEVICEINFO's.  Same with the name strings.  Not asking for it
> to be changed, just about consistency.

The XI2 protocol request for this is in "closed units". So two devices on the
wire look like:

[deviceinfo][name + padding][class 1][class 2][deviceinfo][name + padding][class 1]

This means we loose a few bytes here and there, but at least it's reasonably
sane and much easier to parse.
The length field of the DeviceInfo struct specifies the total length of the
data for this device (sizeof(deviceinfo + sizeof(name) + sizeof(all classes)).
So advancing from one deviceinfo to the next is simpler than in the XI1
implementation.

> It would be nice if this whole extension was more XCB-friendly though. 
> Right now there is no XCB description for some requests because of the
> funky lists of variable-sized subclassed structures.  More description
> in this mail:
> 
> http://lists.freedesktop.org/archives/xcb/2007-December/003166.html

One of the accepted GSoC projects is input support for xcb, so hopefully we
see the matching parsers being added to xcb. XI1 won't change anymore so we
need the parsers anyway.

For XI2, we don't have nested classes (axis class inside valuator class). We
still have variable-sized structs though, but these structs announce their
total length. e.g. the length of a ButtonClass is (len * 4) bytes, and this
includes the trailing atoms.
tbh, I'm not sure how much easier this is for xcb, but having variable length
fields is quite necessary for extensibility.

Cheers,
  Peter