xcbproto issueshttps://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues2024-03-22T02:14:57Zhttps://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/24Generated header fails to compile in c++2024-03-22T02:14:57ZGareth WebbGenerated header fails to compile in c++Hi,
When including `<xcb/xkb.h>` in a c++ file, the compilation fails because `xcb_xkb_set_explicit_t` and `xcb_xkb_set_map_values_t` have fields named `explicit` which is a reserved keyword.
I assume renaming these fields to something ...Hi,
When including `<xcb/xkb.h>` in a c++ file, the compilation fails because `xcb_xkb_set_explicit_t` and `xcb_xkb_set_map_values_t` have fields named `explicit` which is a reserved keyword.
I assume renaming these fields to something else (e.g. _explicit) would be a backwards compatibility nightmare, but is it possible to at least do so when __cplusplus is defined?
The obvious patch is attached, but as I said, breaking change so it's probably not viable to implement: [xkb_explicit_field_name.patch](/uploads/49c9e345df6092220baf6e3d2a6879b6/xkb_explicit_field_name.patch)https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/22xproto.xml misses PointerEvent / DeviceEvent enums2022-08-05T09:33:59ZUli Schlachterxproto.xml misses PointerEvent / DeviceEvent enumsWhat is the situation?
======================
xproto.xml only contains `<enum name="EventMask">` and uses this enumeration for all event masks. However, the X11 core protocol has three different kinds. From https://www.x.org/releases/X1...What is the situation?
======================
xproto.xml only contains `<enum name="EventMask">` and uses this enumeration for all event masks. However, the X11 core protocol has three different kinds. From https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html:
```
SETofEVENT
[SNIP - all the events]
#xFE000000 unused but must be zero
SETofPOINTEREVENT
encodings are the same as for SETofEVENT, except with
#xFFFF8003 unused but must be zero
SETofDEVICEEVENT
encodings are the same as for SETofEVENT, except with
#xFFFFC0B0 unused but must be zero
```
Looking through that document, I find that
- SETofDEVICEEVENT is used for the `do-not-propagate-mask` in CreateWindow and GetWindowAttributes
- SETofPOINTEREVENT is used for the `event-mask` in GrabPointer, GrabButton, ChangeActivePointerGrab
In fact, `do-not-propagate-mask` and `event-mask` are only two bytes large while `SETofEVENT` contains values up to `1 << 24`.
Why is that a problem?
======================
I guess this is not a problem in C thanks to implicit integer conversions. However, I am writing Rust bindings and there the equivalent of `EventMask` can be converted (speaking in C types) to `uint32_t`, but not to `uint16_t`, because there are possible values outside of that range.
See https://github.com/psychon/x11rb/issues/543 and https://github.com/psychon/x11rb/issues/542 and https://github.com/psychon/x11rb/issues/746
What could be done about it?
============================
Of course, adding the two other kinds of event masks to the XML would help. It would also help if these new enums would be used for the affected requests, but I am not sure whether that could break libxcb API/ABI. Hence, I am opening this issue as a place to discuss possible solutions.
Are extensions also affected?
=============================
I'm not sure. `git grep EventMask` suggests that only `screensaver.xml` refers to `EventMask`, but I am not 100% sure. https://www.x.org/releases/X11R7.7/doc/scrnsaverproto/saver.html does not really explain the event mask used in `ScreenSaverSetAttributes`.https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/19XKB's LatchLockState is missing the modLatches field2023-01-10T21:42:47ZMasFlamXKB's LatchLockState is missing the modLatches fieldPer XKB protocol spec the LatchLockState request has the modLatches field. The field in [xkb.xml](/src/xkb.xml#L1208) is commented out, with a note saying it's a "workaround to prevent an API break":
```xml
<request name="LatchLockState"...Per XKB protocol spec the LatchLockState request has the modLatches field. The field in [xkb.xml](/src/xkb.xml#L1208) is commented out, with a note saying it's a "workaround to prevent an API break":
```xml
<request name="LatchLockState" opcode="5">
<field name="deviceSpec" type="DeviceSpec" />
<field name="affectModLocks" type="CARD8" mask="ModMask" />
<field name="modLocks" type="CARD8" mask="ModMask" />
<field name="lockGroup" type="BOOL" />
<field name="groupLock" type="CARD8" enum="Group" />
<field name="affectModLatches" type="CARD8" mask="ModMask" />
<pad bytes="1" /> <!-- This pad is a workaround to prevent an API break,
which the following field (correct fix) would cause.
<field name="modLatches" type="CARD8" mask="ModMask" />
-->
<pad bytes="1" />
<field name="latchGroup" type="BOOL" />
<field name="groupLatch" type="CARD16" />
</request>
```
What could that API break be, if it's a part of the protocol? Isn't it impairing the functionality of XCB?https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/17The reply to XInput's XIGetProperty is incorrectly represented2020-06-25T15:54:39ZUli SchlachterThe reply to XInput's XIGetProperty is incorrectly representedEdit: Original downstream bug report: https://github.com/psychon/x11rb/pull/505
When sending a `XInput` `XIGetProperty` request for a property that does not exist, the code ends up here: https://gitlab.freedesktop.org/xorg/xserver/-/blo...Edit: Original downstream bug report: https://github.com/psychon/x11rb/pull/505
When sending a `XInput` `XIGetProperty` request for a property that does not exist, the code ends up here: https://gitlab.freedesktop.org/xorg/xserver/-/blob/7ae221ad5774756766dc78a73d71f4163ac7b1c6/Xi/xiproperty.c#L266-273
This means that the reply will contain "all zeros". However, "all zeros" is not correct for the `format` field of the reply (`PropertyFormat` only has values 8, 16, 32):
```xml
<field type="CARD8" name="format" enum="PropertyFormat" />
```
Also, the following `<switch>` now has no matching case. I am not quite sure what the semantics of that should (and `doc/xml-xcb.txt` does not really say much either). So far I was assuming that there will always be exactly one match in a `<switch>` containing only `<case>`s.
I am not quite sure what a good fix would be. An ugly one would be (does this cause API changes to libxcb?):
```diff
diff --git a/src/xinput.xml b/src/xinput.xml
index 5f88a98..d91b29a 100644
--- a/src/xinput.xml
+++ b/src/xinput.xml
@@ -1301,6 +1301,13 @@ authorization from the authors.
<!-- GetDeviceProperty -->
+ <enum name="PossiblePropertyFormat">
+ <item name="Missing"> <value>0</value> </item>
+ <item name="8Bits"> <value>8</value> </item>
+ <item name="16Bits"> <value>16</value> </item>
+ <item name="32Bits"> <value>32</value> </item>
+ </enum>
+
<request name="GetDeviceProperty" opcode="39">
<field type="ATOM" name="property" />
<field type="ATOM" name="type" />
@@ -1314,27 +1321,30 @@ authorization from the authors.
<field type="ATOM" name="type" />
<field type="CARD32" name="bytes_after" />
<field type="CARD32" name="num_items" />
- <field type="CARD8" name="format" enum="PropertyFormat" />
+ <field type="CARD8" name="format" enum="PossiblePropertyFormat" />
<field type="CARD8" name="device_id" />
<pad bytes="10" />
<switch name="items">
<fieldref>format</fieldref>
<case>
- <enumref ref="PropertyFormat">8Bits</enumref>
+ <enumref ref="PossiblePropertyFormat">Missing</enumref>
+ </case>
+ <case>
+ <enumref ref="PossiblePropertyFormat">8Bits</enumref>
<list type="CARD8" name="data8">
<fieldref>num_items</fieldref>
</list>
<pad align="4" />
</case>
<case>
- <enumref ref="PropertyFormat">16Bits</enumref>
+ <enumref ref="PossiblePropertyFormat">16Bits</enumref>
<list type="CARD16" name="data16">
<fieldref>num_items</fieldref>
</list>
<pad align="4" />
</case>
<case>
- <enumref ref="PropertyFormat">32Bits</enumref>
+ <enumref ref="PossiblePropertyFormat">32Bits</enumref>
<list type="CARD32" name="data32">
<fieldref>num_items</fieldref>
</list>
@@ -1999,26 +2009,29 @@ authorization from the authors.
<field type="ATOM" name="type" />
<field type="CARD32" name="bytes_after" />
<field type="CARD32" name="num_items" />
- <field type="CARD8" name="format" enum="PropertyFormat" />
+ <field type="CARD8" name="format" enum="PossiblePropertyFormat" />
<pad bytes="11" />
<switch name="items">
<fieldref>format</fieldref>
<case>
- <enumref ref="PropertyFormat">8Bits</enumref>
+ <enumref ref="PossiblePropertyFormat">Missing</enumref>
+ </case>
+ <case>
+ <enumref ref="PossiblePropertyFormat">8Bits</enumref>
<list type="CARD8" name="data8">
<fieldref>num_items</fieldref>
</list>
<pad align="4" />
</case>
<case>
- <enumref ref="PropertyFormat">16Bits</enumref>
+ <enumref ref="PossiblePropertyFormat">16Bits</enumref>
<list type="CARD16" name="data16">
<fieldref>num_items</fieldref>
</list>
<pad align="4" />
</case>
<case>
- <enumref ref="PropertyFormat">32Bits</enumref>
+ <enumref ref="PossiblePropertyFormat">32Bits</enumref>
<list type="CARD32" name="data32">
<fieldref>num_items</fieldref>
</list>
```https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/15xcbgen: Module.direct_imports does not contain all direct imports2020-04-19T08:22:55ZUli Schlachterxcbgen: Module.direct_imports does not contain all direct importsIt took me way to long to figure out this trivial problem, so I want to at least document my findings here.
xinput.xml `<import>`s both xfixes and xproto: https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/2b3559c10c18eb63e61efdc...It took me way to long to figure out this trivial problem, so I want to at least document my findings here.
xinput.xml `<import>`s both xfixes and xproto: https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/2b3559c10c18eb63e61efdc8a030765d624a0fba/src/xinput.xml#L37-38
However, the resulting `xcbgen.Module` instance only contains `xfixes` in its `.direct_imports`. The `xproto` import is lost.
What happens is that first the `xfixes` import is handled here: https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/2b3559c10c18eb63e61efdc8a030765d624a0fba/xcbgen/matcher.py#L27-28
During the import of `xfixes`, `xproto` is imported (because `xfixes` imports `xproto`): https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/2b3559c10c18eb63e61efdc8a030765d624a0fba/src/xfixes.xml#L30
Now, `xproto` is an indirect import, so it is not added to `direct_imports` here (which is correct): https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/2b3559c10c18eb63e61efdc8a030765d624a0fba/xcbgen/state.py#L130-136
Later, the import of `xproto` in `xinput` is parsed. Since `xproto` was already imported, this `<import>` is just ignored here: https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/2b3559c10c18eb63e61efdc8a030765d624a0fba/xcbgen/matcher.py#L27-28
Thus, in the end, `xproto` does not end up in the `direct_imports` of `xinput`.
This issue does not affect libxcb (since it only uses imports for generating `#include` statements and thanks to include guards, the difference that this bug causes is unimportant). Thus, I guess this issue can just be ignored, but I still wanted to at least report my findings.https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/11The tutorial should have a section on error handling2019-02-16T19:40:34ZBugzilla Migration UserThe tutorial should have a section on error handling## Submitted by Steven Stewart-Gallus
Assigned to **xcb mailing list dummy**
**[Link to original bug (#78140)](https://bugs.freedesktop.org/show_bug.cgi?id=78140)**
## Description
The tutorial briefly mentions it in a few points b...## Submitted by Steven Stewart-Gallus
Assigned to **xcb mailing list dummy**
**[Link to original bug (#78140)](https://bugs.freedesktop.org/show_bug.cgi?id=78140)**
## Description
The tutorial briefly mentions it in a few points but doesn't really give a good explanation. This is especially confusing because XCB has two kinds of errors. Errors that the X server sends the program (for example, the client violates the protocol or the server runs out of memory) and errors that the program generates internally (for example, an out of memory error or some low level operating system socket system call generates an IO error).
GUI code is flakey in general and I already run my GUI in a separate process to protect against program exits in library code and corruption but I'd still like to do some obvious error checking.https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/8dynamic protocol bindings2019-02-16T19:40:08ZBugzilla Migration Userdynamic protocol bindings## Submitted by Havoc Pennington
Assigned to **xcb mailing list dummy**
**[Link to original bug (#29743)](https://bugs.freedesktop.org/show_bug.cgi?id=29743)**
## Description
It would be useful to have fast runtime access to somet...## Submitted by Havoc Pennington
Assigned to **xcb mailing list dummy**
**[Link to original bug (#29743)](https://bugs.freedesktop.org/show_bug.cgi?id=29743)**
## Description
It would be useful to have fast runtime access to something like the XML protocol descriptions (but converted to a binary format), similar to gobject-introspection. This would allow language bindings to dynamically generate wrappers on the fly. It would also allow things like xtrace or more one-off debug hacks to use the protocol descriptions.
Even the C binding would have the option to go dynamic. The protocol bindings are not tiny:
$ size /usr/lib/libxcb-glx.so
text data bss dec hex filename
64447 2616 8 67071 105ff /usr/lib/libxcb-glx.so
In theory, each request could be nothing but a call to a dynamic invoker like this:
xcb_send_request_dynamic(connection, flags, request_description, ...);
where "..." would be the args currently passed to the wrapper, and "request_description" would be the binary equivalent of the xml description.
Some notes on this:
* it would be nice to add the request name to the current xcb_protocol_request_t for debugging purposes. supporting lookup of request description given major and minor opcode, for example, would be super useful.
const xcb_request_description_t* xcb_describe_request(int major, int minor)
printf("got request %s\n", xcb_describe_request(major, minor)->name);
* ideally request_description would avoid any references to other symbols. I think e.g. the address of the extension id in xcb_protocol_request_t creates relocations. Qt's moc compiler generates descriptions as one huge string, for example, so there's only one symbol and it points to the read-only data section.
* in principle the xcb protocol wrapper libraries could just be the requests description blob in the library itself, plus headers with macros expanding to xcb_send_request_dynamic. for compat reasons you'd have to make the request-sending APIs functions instead, but they could just be functions that invoke xcb_send_request_dynamic() and nothing else. If the libraries contained only one read-only const symbol (the request description) then they would have notably less overhead than they do now. That's not back compatible, but even reducing each function to be just an invoke of xcb_send_request_dynamic() could result in some nice shrinkage.
* a dynamic setup would perhaps be slightly slower, but the reduced size probably matters more in the real world, and it ought to be pretty fast
* the dynamic setup makes non-C language bindings fixed-size, instead of a multiple of the number of requests the binding supports. (same principle as gobject-introspection)
* http://ometer.com/parallel.html could be used to deprecate the static C bindings
* whatever happens with the C bindings, exporting the "introspection data" at runtime instead of in effectively static-only (due to efficiency issues) XML files would be very useful for debug tools and language bindings.
Does this sound reasonable or does it conflict with some XCB goals?https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/7GLX is missing Render sub-requests2019-02-17T18:06:53ZBugzilla Migration UserGLX is missing Render sub-requests## Submitted by Peter Harris `@peterh`
Assigned to **Josh Triplett**
**[Link to original bug (#13133)](https://bugs.freedesktop.org/show_bug.cgi?id=13133)**
## Description
GLX is missing Render sub-requests. This is critical for x...## Submitted by Peter Harris `@peterh`
Assigned to **Josh Triplett**
**[Link to original bug (#13133)](https://bugs.freedesktop.org/show_bug.cgi?id=13133)**
## Description
GLX is missing Render sub-requests. This is critical for xcb-server, and would be nice for a hypothetical xscope or xmond based on XCB/proto.
At the very least, the TODO file should be updated:
```
diff --git a/TODO b/TODO
index add693c..dfd6a38 100644
--- a/TODO
+++ b/TODO
@@ -12,7 +12,7 @@ X DAMAGE
DOUBLE-BUFFER
X DPMS
Extended-Visual-Information
-X GLX
+I GLX
LBX
X MIT-SCREEN-SAVER
X MIT-SHM
```https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/6PointerRoot for xcb_set_input_focus() missing2019-02-16T19:40:00ZBugzilla Migration UserPointerRoot for xcb_set_input_focus() missing## Submitted by sig..@..cor.de
Assigned to **xcb mailing list dummy**
**[Link to original bug (#89583)](https://bugs.freedesktop.org/show_bug.cgi?id=89583)**
## Description
The PointerRoot (= 1) constant is missing from xproto.xml...## Submitted by sig..@..cor.de
Assigned to **xcb mailing list dummy**
**[Link to original bug (#89583)](https://bugs.freedesktop.org/show_bug.cgi?id=89583)**
## Description
The PointerRoot (= 1) constant is missing from xproto.xml, so it's not in the headers either. However it's mentioned in the docs. It's only used for xcb_set_input_focus().https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/5xproto.xml: ConfigureWindow request with additional 'value_mask' field2019-02-17T18:04:29ZBugzilla Migration Userxproto.xml: ConfigureWindow request with additional 'value_mask' field## Submitted by Jochen Keil
Assigned to **xcb mailing list dummy**
**[Link to original bug (#67782)](https://bugs.freedesktop.org/show_bug.cgi?id=67782)**
## Description
Hello,
In the protocol description for ConfigureWindow ther...## Submitted by Jochen Keil
Assigned to **xcb mailing list dummy**
**[Link to original bug (#67782)](https://bugs.freedesktop.org/show_bug.cgi?id=67782)**
## Description
Hello,
In the protocol description for ConfigureWindow there is an extra "value_mask" field. This field is not used in the generated xcb_configure_window functions.
Since there is already field called "value_mask" for the valueparam, I suspect this is not wanted. This also creates errors when trying to generate functions with two "value_mask" parameters.
```
<request name="ConfigureWindow" opcode="12">
<pad bytes="1" />
<field type="WINDOW" name="window" />
=> <field type="CARD16" name="value_mask" />
<pad bytes="2" />
<valueparam value-mask-type="CARD16"
value-mask-name="value_mask"
value-list-name="value_list" />
```
https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/4various problems with the xkb protocol bindings2019-02-17T14:04:14ZBugzilla Migration Uservarious problems with the xkb protocol bindings## Submitted by Uli Schlachter `@psychon`
Assigned to **xcb mailing list dummy**
**[Link to original bug (#51295)](https://bugs.freedesktop.org/show_bug.cgi?id=51295)**
## Description
While looking at http://lists.freedesktop.org/...## Submitted by Uli Schlachter `@psychon`
Assigned to **xcb mailing list dummy**
**[Link to original bug (#51295)](https://bugs.freedesktop.org/show_bug.cgi?id=51295)**
## Description
While looking at http://lists.freedesktop.org/archives/xcb/2012-June/007800.html, I noticed some more problems with the XKB bindings. Since they won't be fixed any time soon, let's make a meta-bug "xkb is ugly" to make sure that these issues don't get forgetten. So here it is.
The XKB extension has only a single event number. These events contain a xkbType field which then says which kind of event this actually is.
The current xkb.xml describes these events as seperate events, but from the POV of the generator, they are just a single event.
```
<psychon> daniels: <event name="BellNotify" number="8"> <- doesn't the "8" here mean that the event is xkb-event-base + 8?
[...]
<daniels> so technically having them as separate <event>s is wrong i think
<daniels> but i'm not sure how to cover loads of totally disparate events all having the same event type
<pharris> daniels: One event, with a giant <switch>.
[...]
<pharris> daniels: Or possibly a <union>, but I dislike <union> as it doesn't represent well in non-C languages.
```
The second issue is:
```
<enum name="EventType">
[...]
<item name="BellNotify"><bit>8</bit>
</item>
```
This causes a `#define XCB_XKB_EVENT_TYPE_BELL_NOTIFY 256` to be generated, but this actually wants a define with value 8.
The above was noticed while looking at this for 2 minutes and comparing it with Xlib's src/xkb/XKBUse.c, function wire_to_event() and proto/kbproto's X11/extension/XKBproto.h, struct XkbStateNotifyEvent. I bet that a closer inspection would find more problems.https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/3reply element ought to have a "multiple replies" attribute2019-02-16T19:39:45ZBugzilla Migration Userreply element ought to have a "multiple replies" attribute## Submitted by Jamey Sharp `@jamey`
Assigned to **Josh Triplett**
**[Link to original bug (#6801)](https://bugs.freedesktop.org/show_bug.cgi?id=6801)**
## Description
The XML protocol descriptions currently distinguish between re...## Submitted by Jamey Sharp `@jamey`
Assigned to **Josh Triplett**
**[Link to original bug (#6801)](https://bugs.freedesktop.org/show_bug.cgi?id=6801)**
## Description
The XML protocol descriptions currently distinguish between requests that can't
have a reply and those that can have one or more replies. It would be nice if we
could further distinguish between the common case of a request with exactly one
reply, and the quite unusual case of a request with an arbitrary number of replies.
Protocol implementations might use this attribute to detect programming errors
that are otherwise hard or unlikely to detect.https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/2Every structure having a fixed size field after a variadic field/list is broken2019-02-16T19:39:39ZBugzilla Migration UserEvery structure having a fixed size field after a variadic field/list is broken## Submitted by Uli Schlachter `@psychon`
Assigned to **xcb mailing list dummy**
**[Link to original bug (#71758)](https://bugs.freedesktop.org/show_bug.cgi?id=71758)**
## Description
See: http://lists.freedesktop.org/archives/xcb...## Submitted by Uli Schlachter `@psychon`
Assigned to **xcb mailing list dummy**
**[Link to original bug (#71758)](https://bugs.freedesktop.org/show_bug.cgi?id=71758)**
## Description
See: http://lists.freedesktop.org/archives/xcb/2013-October/008689.html
To quote from that mail (more details are in there):
First, the summary if you don't want to read the whole story: It looks
like _every_ structure having a fixed size field after a variadic
field/list is broken! Most other extensions are not affected as they've
the variadic stuff at the end of a structure - not intermixed with fixed
size fields.
[...]
This struct has a
- fixed size field (nameLength)
- variadic list (name)
- fixed size field (valueLength)
- variadic list (value).
Now, look at the generated structure:
typedef struct xcb_xkb_property_t {
uint16_t nameLength;
uint16_t valueLength; <-- doesn't belong here
} xcb_xkb_property_t;https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/1sync extension CreateAlarm needs valueparam with mixture of INT64 and CARD32 ...2019-02-16T19:39:34ZBugzilla Migration Usersync extension CreateAlarm needs valueparam with mixture of INT64 and CARD32 values## Submitted by Aaron
Assigned to **xcb mailing list dummy**
**[Link to original bug (#23404)](https://bugs.freedesktop.org/show_bug.cgi?id=23404)**
## Description
Currently, sync.xml defines the CreateAlarm request with a CARD32 ...## Submitted by Aaron
Assigned to **xcb mailing list dummy**
**[Link to original bug (#23404)](https://bugs.freedesktop.org/show_bug.cgi?id=23404)**
## Description
Currently, sync.xml defines the CreateAlarm request with a CARD32 value-mask/value-list field. However, the value and delta parameters are defined as INT64. Unfortunately, it seems like the current implementation of valueparam does not accommodate this type of construct.https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/20Lots of missing documentation2021-07-20T20:24:35ZDemi Marie Obenourdemiobenour@gmail.comLots of missing documentationMany extensions are missing documentation.Many extensions are missing documentation.https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/18Documentation error in xcb/xproto.h2021-06-05T16:56:49ZFrank EskesenDocumentation error in xcb/xproto.hThe ButtonIndex information in https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/master/src/xproto.xml starting at line 2711 is incorrect. By experimentation, the actual button numbers provided in xcb_button_press_event::detail a...The ButtonIndex information in https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/master/src/xproto.xml starting at line 2711 is incorrect. By experimentation, the actual button numbers provided in xcb_button_press_event::detail are:
1 Left button (correctly commented)\
2 Center (wheel press) button (You have left)\
3 Right button (You have center)\
4 Scroll wheel (Direction: Push or Away, you have ?)\
5 Scroll wheel (Direction: Pull or Toward, you have ?)\
6 (I don't know either)\
7 (I don't know either)\
8 Scroll wheel left (You don't specify) You get this by pushing the scroll wheel to the left.\
9 Scroll wheel right (You don't specify) Pushing the wheel to the right get this.
You define the buttons by number with comments rather than directly by function. I suggest renaming them to XCB_BUTTON_INDEX_{LEFT|CENTER|RIGHT} and XCB_WHEEL_INDEX_{LEFT|CENTER|RIGHT|PUSH|PULL}, although you might prefer XCB_BUTTON_INDEX_WHEEL_{...}. The names push and pull describes how the fingers act using the wheel, pushing it away from or pulling it toward yourself. You might also want to move these values closer to and document them as the xcb_button_press_event detail field.https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/10no description of xcb_event_mask_t event type2019-02-16T19:40:32ZBugzilla Migration Userno description of xcb_event_mask_t event type## Submitted by Julien Hebert
Assigned to **xcb mailing list dummy**
**[Link to original bug (#69598)](https://bugs.freedesktop.org/show_bug.cgi?id=69598)**
## Description
there is just event list on http://xcb.freedesktop.org/man...## Submitted by Julien Hebert
Assigned to **xcb mailing list dummy**
**[Link to original bug (#69598)](https://bugs.freedesktop.org/show_bug.cgi?id=69598)**
## Description
there is just event list on http://xcb.freedesktop.org/manual/group__XCB____API.html no description.