The specification says that Property is a struct of two CountedString16
(name and value). This form can't be handled atm. correctly too. But,
add it as a comment so we've it at hand when we know what to do with it.
All credits go to Ran Benita, as he found this.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
c_client.py doesn't handle such intermixed fixed size fields and lists
correctly. Therefor comment them out.
With that change the size of the generated request structure for
ListComponents has 8 Bytes which is the same as xkbListComponentsReq
has and the server checks REQUEST_AT_LEAST_SIZE(xkbListComponentsReq).
The same goes for GetKbdByName, which results in a structure of 12
Bytes.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
This struct has intermixed fixed size fields and lists, which
c_client.py doesn't handle properly. Therefor comment out the struct and
the fields type-referencing it.
As doodads are commented out already and with Property gone the requests
GetGeomtry and SetGeometry become pretty much useless. Therefor comment
them out completly.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
Doodads are known to be broken (*). Comment them out until they can be
handled properly.
(*) One problem is that TextDoodad and LogoDoodad have variadic lists at
the end. But, they're within a union with other fixed size Doodads. A
union doesn't have a hint which field is in use and therefor the code
generator (at least c_client.py) just creates a generic iterator for the
Doodad union, which fails for TextDoodad and LogoDoodad.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
Add a file HACKING describing howto to prettify patches (their hunk
headers) and add src/.gitattributes, which is necessary for that.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
This adds an enumeration 'XIEventMask', which is necessary to select for
XI2 events via the SelectEvent request.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
These are present in the API, but not present on the wire.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is used by libxcb, and was defined explicitly there but it's
cleaner to use the XML specification.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Harris <pharris@opentext.com>
No reason to make people use two 32-bit values when every modern
compiler has native 64-bit objects.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This makes sure we use the crazy sync-specific 64-bit datatype instead
of the global INT64 type
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Harris <pharris@opentext.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
AXOption can be an <enum> instead of a <union>, which is a much simpler
construct.
Signed-off-by: Peter Harris <pharris@opentext.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
The field ledId is of type CARD16, not CARD8, see XKBproto.h.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
* CommonDoodad is xkbAnyDoodadWireDesc in XKBproto.h. There it has a
size of 20 like all Doodads:
#define sz_xkbAnyDoodadWireDesc 20
Add the necessary 8 bytes of padding.
* SALockDeviceBtn is an Action. All Actions are handled by the server
and libX11 with sizeof(xkbActionWireDesc) or
SIZEOF(xkbActionWireDesc). Which results in a size of 8:
#define sz_xkbActionWireDesc 8 /* in XKBproto.h */
Add the necessary 3 bytes of padding.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
The first field has to be 'format' not a pad and 'num_items' is of type
CARD32.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Arnaud Fontaine <arnau@debian.org>
Do not allow enum items without an explicit bit or value. The value of
an enum item is known when adding the enum to the xml specification.
There's no reason why this information shouldn't be where it belongs to.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com> (and tested)
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
