xcbproto issueshttps://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues2019-02-16T19:40:00Zhttps://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/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/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/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/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/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/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.