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 +, -, *, /, &, and 298 <<, 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