xml-xcb.txt revision a27842ff
1                                  xcb/proto
2
3Description
4===========
5
6xcb/proto is a set of XML files describing the  X Window System protocol
7It is designed for use with libxcb, the X C binding
8<http://xcb.freedesktop.org/>.  xcb/proto consists of:
9
10xcb.xsd      An XML Schema defining the data format for describing the X
11             protocol.
12
13*.py         Code generator helpers that read the protocol descriptions
14             into python structures. See libxcb for example usage.
15
16*.xml        XML descriptions of the core X protocol and many extensions.
17
18
19Generating C bindings
20=====================
21
22See libxcb <http://cgit.freedesktop.org/xcb/libxcb/>.
23
24
25Protocol Description Format
26===========================
27
28Root element
29------------
30
31<xcb header="string" extension-name="string" extension-xname="string">
32  top-level elements
33</xcb>
34
35  This is the root element of a protocol description.  The attributes are all
36  various forms of the extension name.  header is the basename of the XML
37  protocol description file, which will be used as the basename for generated
38  bindings as well.  extension-name is the name of the extension in InterCaps,
39  which will be used in the names of functions.  extension-xname is the name
40  of the extension as passed to QueryExtension.
41
42  As an example, the XML-XCB description for the GO-FASTER extension would use
43  the root element <xcb header="gofaster" extension-name="GoFaster"
44  extension-xname="GO-FASTER">; as a result, C bindings will be put in
45  gofaster.h and gofaster.c, extension functions will be named
46  XCBGoFasterFunctionName, and the extension initialization will call
47  QueryExtension with the name "GO-FASTER".
48
49  This element can contain any number of the elements listed in the section
50  "Top-Level Elements" below.
51
52
53Top-Level Elements
54------------------
55
56<import>header_name</import>
57
58  The import element allows the protocol description to reference types
59  declared in another extension.  The content is be the basename of the
60  extension XML file, which is also the header attribute of the extension's
61  root node.  Note that types from xproto are automatically available, without
62  explicitly importing them.
63
64<struct name="identifier">structure contents</struct>
65
66  This element represents a data structure.  The name attribute gives the name
67  of the structure.  The content represents the fields of the structure, and
68  consists of one or more of the field, pad, and list elements described in
69  the section "Structure Contents" below.
70
71<union name="identifier">structure contents</union>
72
73  This element represents a union of data types, which can hold one value of
74  any of those types.  The name attribute gives the name of the union.  The
75  content represents the fields of the union, and consists of one or more of
76  the field and pad elements described in the section "Structure Contents
77  below".
78
79<eventstruct name="identifier">event-type-selector list</struct>
80
81  This element represents a data structure that is the wire-representation of
82  an event. The event can be any type that's selected by the
83  event-type-selector list.
84
85<xidtype name="identifier" />
86
87  This element represents an identifier for a particular type of resource.
88  The name attribute gives the name of the new type.
89
90<enum name="identifier">
91  <item name="identifier">[optional expression]</item>
92  ...
93</enum>
94
95  The enum element represents an enumeration type, which can take on any of
96  the values given by the contained item elements.  The name attribute on the
97  enum gives the name of the enumerated type.
98
99  The item element represents one possible value of an enumerated type.  The
100  name attribute on the item gives the name of that value, and the optional
101  content is an expression giving the numeric value.  If the expression is
102  omitted, the value will be one more than that of the previous item, or 0 for
103  the first item.
104
105<typedef oldname="identifier" newname="identifier" />
106
107  The typedef element declares the type given by the newname attribute to be
108  an alias for the type given by the oldname attribute.
109
110<request name="identifier" opcode="integer" [combine-adjacent="true"]>
111  structure contents
112  [<reply>structure contents</reply>]
113</request>
114
115  The request element represents an X protocol request.  The name attribute
116  gives the name of the request, and the opcode attribute gives the numeric
117  request code.  The content of the request element represents the fields in
118  the request, and consists of one or more of any of the elements listed in
119  the "Structure Contents" section below.  Note that for requests in the core
120  protocol, the first field in the request goes into the one-byte gap between
121  the major opcode and the length; if the request does not have any data in
122  that gap, put a one byte pad as the first element.  Extension requests
123  always have this gap filled with the minor opcode.
124
125  The optional reply element is present if the request has a reply.  The
126  content of the reply element represents the fields in the reply, and
127  consists of zero or more of the field, pad, and list elements listed in the
128  "Structure Contents" section below.  Note that the first field in the reply
129  always goes into the one-byte gap between the response type and the sequence
130  number; if the reply does not have any data in that gap, put a one byte pad
131  as the first element.
132
133  If the optional combine-adjacent attribute is true, multiple adjacent
134  requests of the same type may be combined into a single request without
135  affecting the semantics of the requests.
136
137<event name="identifier" number="integer"
138       [[no-sequence-number="true"] | [xge="true"]]>
139  structure contents
140</event>
141
142  This element represents an X protocol event.  The name attribute gives the
143  name of the event, and the number attribute gives the event number.  The
144  content of the event element represents the fields in the event, and
145  consists of zero or more of the field, pad, and list elements listed in the
146  "Structure Contents" section below.
147
148  If the optional no-sequence-number attribute is true, the event does not
149  include a sequence number.  This is a special-case for the KeymapNotify
150  event in the core protocol, and should not be used in any other event.
151
152  If the optional xge attribute is true, the event is an X Generic Event and
153  will be treated as such.
154
155  The no-sequence-number and xge attribute can not be combined.
156
157<error name="identifier" number="integer">
158  structure contents
159</error>
160
161  This element represents an X protocol error.  The name attribute gives the
162  name of the error, and the number attribute gives the error number.  The
163  content of the error element represents the fields in the error, and
164  consists of zero or more of the field, pad, and list elements listed in the
165  "Structure Contents" section below.
166
167<eventcopy name="identifier" number="identifier" ref="identifier" />
168
169  This element creates an alias for the event named in the ref attribute, with
170  the new name given in the name attribute, and the new event number given in
171  the number attribute.
172
173<errorcopy name="identifier" number="identifier" ref="identifier" />
174
175  This element creates an alias for the error named in the ref attribute, with
176  the new name given in the name attribute, and the new error number given in
177  the number attribute.
178
179
180Structure Contents
181------------------
182
183Note: "type" attributes below refer to types defined by previous elements,
184either in the current extension, xproto, or one of the imported extensions.
185The type name must refer to only one possible type; if more than one type
186matches, an error occurs.  To avoid this, the type may be explicitly prefixed
187with a namespace, which should be the value of the header attribute on the
188protocol description containing the desired type.  The namespace and type are
189separated by a single colon.  For example, to refer to the PIXMAP type defined
190in glx rather than the one defined in xproto, use type="glx:PIXMAP" rather
191than type="PIXMAP".
192
193Note: Most of the below may optionally contain an enum, altenum, mask or altmask
194attribute, which follows the above rules for "type". "enum" is an exhaustive
195enum; the value is restricted to one of the constants named in the enum.
196"altenum" may be one of the values contained in the enum, but it need not be.
197"mask" refers to an exhaustive enum to be used as a bitmask.
198"altmask" may be a mask from the referred enum, but it need not be.
199
200<pad bytes="integer" serialize="bool" />
201
202  This element declares some padding in a data structure.  The bytes
203  attribute declares the number of bytes of padding.
204
205  If serialize="true", then the pad will be serialized/deserialized.
206  This is only needed for ABI compatibility with legacy.
207  Newly added pads should not be defined with serialize="true".
208
209  The serialize attribute may be omitted.
210  Default is serialize="false".
211
212<field type="identifier" name="identifier" />
213
214  This element represents a field in a data structure.  The type attribute
215  declares the data type of the field, and the name attribute gives the name
216  of the field.
217
218<fd name="identifier" />
219
220  This element represents a file descriptor field passed with the request.  The
221  name attribute gives the name of the field.
222
223  While ordinary fields are encoded as part of the request, file descriptor
224  fields are generally passed via an out-of-band mechanism.
225
226<list type="identifier" name="identifier">expression</list>
227
228  This element represents an array or list of fields in a data structure.  The
229  type attribute declares the data type of the field, and the name attribute
230  gives the name of the field.  The content is an expression giving the length
231  of the list in terms of other fields in the structure.  See the section
232  "Expressions" for details on the expression representation.
233
234<exprfield type="identifier" name="identifier">expression</exprfield>
235
236  This element represents a field in a request that is calculated rather than
237  supplied by the caller.  The type attribute declares the data type of the
238  field, and the name attribute gives the name of the field.  The content is
239  the expression giving the value of the field.  See the section "Expressions"
240  for details on the expression representation.
241
242<valueparam value-mask-type="identifier" value-mask-name="identifier"
243            value-list-name="identifier" />
244
245  This element represents a BITMASK/LISTofVALUE parameter pair: a bitmask
246  defining the set of values included, and a list containing these values.
247  value-mask-type gives the type of the bitmask; this must be CARD16 or
248  CARD32.  value-mask-name gives the field name of the bitmask, and
249  value-list-name gives the field name of the list of values. Please use
250  <switch> instead for new protocol definitions.
251
252<switch name="identifier"> switch expression
253    <bitcase [name="identifier"]> bitcase expression(s), fields </bitcase>
254    <case [name="identifier"]> case expression(s), fields </case>
255</switch>
256
257  This element represents conditional inclusion of fields. It can be viewed
258  as sequence of multiple ifs:
259
260  <bitcase>:
261    if ( switch expression & bitcase expression ) is non-zero,
262    bitcase fields are included in structure.
263
264  <case>:
265    if ( switch expression == case expression ) is true,
266    then case fields are included in structure.
267
268  It can be used only as the last field of a structure.
269
270  When a bitcase or case includes multiple <enumref> clauses, the contents
271  of the bitcase or case are only present once regardless of the number of
272  bitcase or case expressions that match.
273
274  <enumref> inside <bitcase> can only refer to an enum's <bit> members.
275  <enumref> inside <case> can only refer to an enum's <value> members.
276
277  A switch may contain multiple <bitcase> or <case> elements.
278  Usually it will only contain <bitcase> elements
279  or only contain <case> elements.
280  That is, mixing of <case> and <bitcase> usually doesn't make any sense.
281
282  The same value may appear in multiple <case> or <bitcase> elements.
283
284  New protocol definitions should prefer to use this instead of <valueparam>
285  and instead of <union>.
286
287
288Expressions
289-----------
290
291  Expressions consist of a tree of <op> elements with leaves consisting of
292  <fieldref> or <value> elements.
293
294<op op="operator">expression expression</op>
295
296  The op element represents an operator, with the op attribute specifying
297  which operator.  The supported operations are +, -, *, /, &amp;, and
298  &lt;&lt;, and their semantics are identical to the corresponding operators
299  in C.  The two operand expressions may be other expression elements.
300
301<fieldref>identifier</fieldref>
302
303  The fieldref element represents a reference to the value of another field in
304  the structure containing this expression.  The identifier is the value of
305  the "name" attribute on the referenced field.
306
307<paramref type="type">identifier</paramref>
308
309  A paramref is similar to a fieldref, but it refers to the value of
310  a field in the context which refers to the struct which contains the paramref.
311
312  So, it refers to a field outside of the structure where it is defined.
313  This has the following consequences:
314  * The generator cannot deduce its type.
315    So, it is mandatory to specify its type.
316  * The identifier-name must not be used as a field in the structure
317    which contaons the paramref.
318
319  For an example, see struct "DeviceTimeCoord" and request/reply
320  "GetDeviceMotionEvents" in xinput.xml, where paramref "num_axes"
321  in struct DeviceTimeCoord refers to field "num_axes" in
322  the DeviceTimeCoord reply.
323
324<value>integer</value>
325
326  The value element represents a literal integer value in an expression.  The
327  integer may be expressed in decimal or hexadecimal.
328
329<bit>integer</bit>
330
331  The bit element represents a literal bitmask value in an expression.
332  The integer must be in the range 0..31, expanding to (1<<n) in C.
333
334<enumref ref="identifier">enum item identifier</enumref>
335
336  This element represents a reference to item of enum.
337
338<unop op="operator">expression</unop>
339
340  This element represents a unary operator, with the op attribute specifying
341  which operator. The only supported operation so far is ~, and its semantic
342  is identical to the corresponding operator in C.
343
344<sumof ref="identifier" />
345
346  This element represents a sumation of the elements of the referenced list.
347
348<sumof ref="identifier" >expression</sumof>
349
350  The expression is evaluated for each element of the referenced list,
351  in the context of this element.
352  This sumof element then represents a sumation of the results of these
353  evaluations.
354
355  expression will usually be a fieldref which references a field of
356  a list-element or an expression containing a fieldref,
357  such as popcount of a fieldref.
358
359<popcount>expression</popcount>
360
361  This element represents the number of bits set in the expression.
362
363<listelement-ref/>
364
365  This element represents the current list-element when used inside
366  a list-iteration expression such as <sumof>.
367
368
369Event-Type-Selector List
370------------------------
371
372  The event-type-selector list selects a set of eventtypes.
373  It consists of any number of the following elements:
374
375  <allowed extension="identifier" xge="boolean"
376           opcode-min="integer" opcode-max="integer" />
377
378  The extension attribute selects events from the given extension.
379
380  If the xge attribute is true, the event is an X Generic Event and
381  will be treated as such.
382
383  opcode-min and opcode-max describe the minimum and maximum opcode
384  respectively. The opcode is the same number as the number-attribute
385  of an event definition. I.e. this is the offset from the event-base
386  to the actual number used on the wire.
387
388  In the current implementation, only xge="false" is supported.
389
390
391Documentation
392-------------
393
394  Documentation for each request, reply or event is stored in the appropriate
395  element using a <doc> element. The <doc> element can contain the following
396  elements:
397
398<brief>brief description</brief>
399
400  A short description of the request, reply or event. For example "makes a
401  window visible" for MapWindow. This will end up in the manpage NAME section
402  and in the doxygen @brief description.
403
404<description><![CDATA[longer description]]></description>
405
406  The full description. Use `` to highlight words, such as "Draws
407  `points_len`-1 lines between each pair of points…"
408
409<example><![CDATA[example code]]</description>
410
411  Example C code illustrating the usage of the particular request, reply or
412  event.
413
414<field name="name">field description</field>
415
416  The full description for the specified field. Depending on the context, this
417  is either a request parameter or a reply/event datastructure field.
418
419<error type="type">error description</field>
420
421  The full description for an error which can occur due to this request.
422
423<see type="request" name="name" />
424
425  A reference to another relevant program, function, request or event.
426