xinput: Cleanup implementation of XI up to v1.4

- Structural changes:
  * indent with spaces only (replaced tabs)
  * indent attributes
  * move structures in front of the first request using it
    (Otherwise c_client.py would generate uncompileable code if we fix
     the uninterpreted lists.)
  * add version-controlled section comments (types, requests, events,
    errors) and move structures into their corresponding section
  * sort events and eventcopys by number

- Additions:
  * add various missing enums and structs (i.e. DeviceChange,
    DeviceControl, DeviceName, ...)
  * uncomment commented out requests
  * linked in various enums into fields (via enum or altenum)

- Other changes:
  * link to the txt specification in the git repo
  * fixed comments for "uninterpreted lists"

- API CHANGES:
  * Request: GetDeviceMotionEvents
    The reply contains a list of events (of coordinates). So, we rename
    num_coords to num_events. The field is called nevents_return in the
    specification. The list was commented out anyways, so the rename
    shouldn't affect that much.
  * Request: SendExtensionEvent
    The list 'events' is a mask, make it a CARD8 like every other mask.
  * Events: FocusIn/Out
    Those ones haven't been named properly. They are called
    DeviceFocusIn/Out in the specification. In XI2 the names FocusIn/Out
    are used to introduce new events and cause name clashes. So, we have
    to rename the existing FocusIn/Out and give them their proper names.
  * Structures: *Feedback{Ctl,State}
    Rename the field id to feedback_id, as it's called in the spec. The
    only lists using those structs are commented out yet. So, this might
    not be called an api break.

Signed-off-by: Daniel Martin <consume.noise@gmail.com>
xinput: Add XI v1.5

New:
- Requests
  * ListDeviceProperties
  * ChangeDeviceProperty
  * DeleteDeviceProperty
  * GetDeviceProperty

- Enum
  * PropertyFormat

- Event
  * DevicePropertyNotify

The requests ChangeDeviceProperty and GetDeviceProperty use switches to
return a list depending on the format (8bit, 16bit and 32bit) of the
property value.
We reuse the <bitcase> here. Which is possible, because the format
values don't have equal bits. But, this is rather a hack and must be
changed when the value test (a <case>) for switches is implemented.

Signed-off-by: Daniel Martin <consume.noise@gmail.com>
xinput: Add XI v2.0

Introduced with v2.0 have been various new types, structures, 21
requests and 12 XGE events.

All new requests have the "XI" prefix in the name. This prefix can be
found in the spec too and avoids name clashes with requests found in
prior versions of XI (at least that's (Un)GrabDevice).

All new events are X Generic Events. They've a different header then
"normal" events. Therefor we've to mark them with the attribute 'xge'
set to 'true'.

To prevent another name clash one new structure had to be prefixed,
too: XIDeviceInfo.

Signed-off-by: Daniel Martin <consume.noise@gmail.com>
xinput: Add XI v2.1

Introduced with v2.1 has been Raw event support and therefor 5 new
events: Raw{Key,Button}{Press,Release} and RawMotion.

Signed-off-by: Daniel Martin <consume.noise@gmail.com>
xinput: Add XI v2.2

Introduced with v2.2 has been Multitouch support and therefor 7 new
events: (Raw)Touch{Begin,Update,End} and TouchOwnership.

Signed-off-by: Daniel Martin <consume.noise@gmail.com>
xinput: Add XI v2.3

Introduced with v2.3 has been Pointer Barrier support, including a new
request (XIBarrierReleasePointer) and 2 events (Barrier{Hit,Leave}).

Signed-off-by: Daniel Martin <consume.noise@gmail.com>
xinput: Unlock uninterpreted lists

The 'uninterpreted_data' lists have been added to pad the structure at
runtime and thereby making lists of such structures iterable.

This is a temporary solution until it is possible to nest a <switch> in
a <struct> correctly.

Signed-off-by: Daniel Martin <consume.noise@gmail.com>
xinput: Use BARRIER from xfixes

Signed-off-by: Daniel Martin <consume.noise@gmail.com>
xproto: Fix GContext error references in documentation

The name of the error is GContext, not GC.

Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
xkb: Work around alignment problems in GetNames and GetMap replies

The basic situation is this: a list of CARD8/CARD16s followed by a list
of CARD16/CARD32s. In the current code, the second list is aligned to
1/2 bytes according the size of the first list. However, in some cases
the second list needs to be aligned to 4 bytes per the xkbproto spec:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#appD::Requests

XkbGetMap reply (xkb-opcode 8):
[...]
a     LISTofCARD8          actsRtrn.count
p               unused,p=pad(a)
8A     LISTofKB_ACTION          actsRtrn.acts
4B     LISTofKB_SETBEHAVIOR          behaviorsRtrn
v     LISTofSETofKEYMASK          vmodsRtrn
p               unused, p=pad(v)
2E     LISTofKB_SETEXPLICIT          explicitRtrn
p               unused,p=pad(2E)
2M     LISTofKB_KEYMODMAP          modmapRtrn
p               unused, p=pad(2M)
[...]

XkbGetNames reply (xkb-opcode 17):
[...]
l     LISTofCARD8          nLevelsPerType, sum of all elements=L
p               unused, p=pad(l)
[...]

The server and Xlib handle this with calls to XkbPaddedSize(), which is
a good way to see where the extra padding is needed.

Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
xkb: Fix key type map entry field order

In fact, unlike the deleted comment says, both Xlib and the server use
the order as specified in the protocol spec:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#appD::Requests
(Search for KB_KTMAPENTRY).

Also see struct xkbKTMapEntryWireDesc in
/usr/include/X11/extensions/XKBproto.h

Reviewed-by: Peter Harris <pharris@opentext.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb: Change DfltBtnAbsolute to the value used by the server

The spec says:
     #x02     XkbSA_DfltBtnAbsolute
But /usr/include/X11/extensions/XKB.h has:
     #define	XkbSA_DfltBtnAbsolute	(1L << 2)
which is what the server sends.

Note: the XKB spec was changed by Daniel Martin to match the Xlib value.
See kbproto commit db07706cb268d5fe1bc38ef5c0a9f49309068b2c.

Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb: Unify Overlay1Behavior and Overlay2Behavior

These two structs are used by the server in the exact same way, and are
handled together (see xkb/xkbPrKeyEv.c, XkbKB_Overlay{1,2} handling).
There is no need to use different (and for some reason slightly
different) types for them.

Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb: Add missing 'supported' field to GetNamedIndicator reply

The protocol encoding has it:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#appD::Requests

    1     CARD8          opcode
    1     15          xkb-opcode
    [...]

    1     1          Reply
    1     CARD8          deviceID
    2     CARD16          sequence number
    [...]
    4     SETofKB_BOOLCTRL          map.ctrls
    1     BOOL          supported
    3               unused

And xkbGetNamedIndicatorReply in XKBproto.h also.

Finally, the server does send it, though it's always TRUE.

Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
xkb: Add missing LedClass and BellClass enum values

The protocol encoding says:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#appD::Common_Types

    KB_LEDCLASSRESULT
        0     KbdFeedbackClass
        4     LedFeedbackClass

    KB_LEDCLASSSPEC
        Encoding same as KB_LEDCLASSRESULT, with the addition of:
        #x0300     XkbDfltXIClass
        #x0500     XkbAllXIClasses

    KB_BELLCLASSRESULT
        0     KbdFeedbackClass
        5     BellFeedbackClass

    KB_BELLCLASSSPEC
        Encoding same as KB_BELLCLASSRESULT, with the addition of:
        #x0300     XkbDfltXIClass

Note that the spec says something slightly different in another section:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Common_Types

    KB_LEDCLASSSPEC { KbdFeedbackClass , LedFeedbackClass , DfltXIClass , AllXIClasses , XINone }
    KB_BELLCLASSSPEC    { KbdFeedbackClass , BellFeedbackClass , DfltXIClass , AllXIClasses  }}

From what I could gather, the encoding is the correct one (but I'm not
sure).

Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>