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>
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>
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>
- 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>
With these patches, we are able to mark an XGE event as such and
generate the correct header for it.
XGE events can be found in the X Input Extension v2++.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
Values for "Value" and "Delta" fields are 64-bit that couldn't be passed through a regular value list/mask.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
And make use of it in ClientIdSpec.
v2: use <bit/> instead of <value/> in the enum
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
The list is a CARD32 and rename the field to "value" to match the
specification.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
With RandR 1.4 provider objects have been introduced. "A provider object
represents a GPU or virtual device providing services to the X server."
To handle provider objects the following requests have been added:
- GetProviders
- GetProviderInfo
- SetProviderOffloadSink
- SetProviderOutputSource
- ListProviderProperties
- QueryProviderProperty
- ConfigureProviderProperty
- ChangeProviderProperty
- DeleteProviderProperty
- GetProviderProperty
And the Notify event got 3 new subcodes:
- ProviderChange
- ProviderProperty
- ResourceChange
v2:
- add missing name field to GetProviderInfo
v3:
- changed ProviderCapability enum
o replaced <value> with <bit>
o removed None
- replaced "alignment pad list" with commented out <pad align="4"/> to
be prepared for future enhancements
- add brief description to commit msg about additions
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
