libxcb issueshttps://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues2019-02-17T10:53:26Zhttps://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/35XCB codegen should give a meaningful error message on malformed fieldref2019-02-17T10:53:26ZBugzilla Migration UserXCB codegen should give a meaningful error message on malformed fieldref## Submitted by Trevour
Assigned to **xcb mailing list dummy**
**[Link to original bug (#36056)](https://bugs.freedesktop.org/show_bug.cgi?id=36056)**
## Description
Take the following example protocol:
<?xml version="1.0" encodi...## Submitted by Trevour
Assigned to **xcb mailing list dummy**
**[Link to original bug (#36056)](https://bugs.freedesktop.org/show_bug.cgi?id=36056)**
## Description
Take the following example protocol:
<?xml version="1.0" encoding="utf-8"?>
`<xcb header="bad" extension-name="bad" extension-xname="BAD">`
`<request name="BadRequest" code="0">`
<field type="CARD32" name="sizeField" />
`<list type="CARD8" name="dataVector">`
`<fieldref>`vectorSize`</fieldref>`
`</list>`
`</request>`
`</xcb>`
When running it through XCB's codegen, the result is a backtrace and a TypeError that NoneType can't be concatenated with 'str'. As it stands, the error gives no hint that the issue is that vectorSize isn't a previously defined field in the request, which can be easily overlooked(especially if the error is a simple shift failure). Not having any experience in Python, I can't suggest what would be the best fix, but it looks like adding a check in get_type_impl(state.py) for id == NoneType should be sufficient for a simple "Check your fieldrefs" diagnostic.https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/32XCB should zero out padding bytes2021-07-30T12:43:28ZBugzilla Migration UserXCB should zero out padding bytes## Submitted by Jamey Sharp `@jamey`
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#5958)](https://bugs.freedesktop.org/show_bug.cgi?id=5958)**
## Description
To make valgrind quit complaining and, supposedly, impr...## Submitted by Jamey Sharp `@jamey`
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#5958)](https://bugs.freedesktop.org/show_bug.cgi?id=5958)**
## Description
To make valgrind quit complaining and, supposedly, improve protocol stream
compression, padding bytes in requests generated by XCB should be zeroed before
transmission.https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/31xcb_auth.c doesn't treat ipv6-mapped ipv4-addresses correctly2019-02-17T20:39:24ZBugzilla Migration Userxcb_auth.c doesn't treat ipv6-mapped ipv4-addresses correctly## Submitted by Christoph Pfister
Assigned to **xcb mailing list dummy**
**[Link to original bug (#20665)](https://bugs.freedesktop.org/show_bug.cgi?id=20665)**
## Description
from irc:
`<no_where>` I believe I have found a bug i...## Submitted by Christoph Pfister
Assigned to **xcb mailing list dummy**
**[Link to original bug (#20665)](https://bugs.freedesktop.org/show_bug.cgi?id=20665)**
## Description
from irc:
`<no_where>` I believe I have found a bug in libxcb: src/xcb_auth.c. Line 190 reads:
`<no_where>` APPEND(info->data, j, si6->sin6_addr.s6_addr[12]);
`<no_where>` As far as I can see, this will copy exactly one byte, because sizeof(si6->sin6_addr.s6_addr[12]) is 1. But it should copy four bytes, namely the IPv6-mapped IPv4-address from bytes 12 through 15.
`<no_where>` Can some knowledgable person confirm this, and if this analysis is correct, file a bug report?
`<christoph4>` no_where: hmm, your statement makes sense
`<no_where>` christoph4: at least in the old libX11/.../ConnDis.c, 4 bytes were copied explicitly
i've checked the xcb_auth.c code of current git head, and it matches the descriptionhttps://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/30Expand on API docs2019-02-16T19:41:40ZBugzilla Migration UserExpand on API docs## Submitted by Havoc Pennington
Assigned to **xcb mailing list dummy**
**[Link to original bug (#29655)](https://bugs.freedesktop.org/show_bug.cgi?id=29655)**
## Description
Created attachment 37965
more docs!
This patch adds qu...## Submitted by Havoc Pennington
Assigned to **xcb mailing list dummy**
**[Link to original bug (#29655)](https://bugs.freedesktop.org/show_bug.cgi?id=29655)**
## Description
Created attachment 37965
more docs!
This patch adds quite a bit more detail to the API documentation.
It assumes the small docs patch in [bug 29599](https://bugs.freedesktop.org/show_bug.cgi?id=29599) has been applied.
There are probably some mistakes in here, but hopefully someone more "in the know" can fix those.
I think it's useful to give a lot more detail about what blocks and what doesn't, how buffering and flushing works, and even spell out some basic info about the X protocol. So I tried to put that kind of thing in here.
I copied a few lines of xcbext.h docs from the wiki, but mostly had to write new docs for it.
These docs could probably still use more info about how to use XCB with threads,
but I haven't sat down and tried to work that out, so I didn't document it.
**Patch 37965**, "more docs!":
[Add-lots-more-detail-to-the-xcb.h-and-xcbext.h-API-d.patch](/uploads/c7d099c08a96650c5431c008ed0fb727/Add-lots-more-detail-to-the-xcb.h-and-xcbext.h-API-d.patch)https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/29Errors and events should include their 32-bit sequence number2019-02-16T19:41:35ZBugzilla Migration UserErrors and events should include their 32-bit sequence number## Submitted by Jamey Sharp `@jamey`
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#6105)](https://bugs.freedesktop.org/show_bug.cgi?id=6105)**
## Description
Currently, XCB hands errors and events back to the call...## Submitted by Jamey Sharp `@jamey`
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#6105)](https://bugs.freedesktop.org/show_bug.cgi?id=6105)**
## Description
Currently, XCB hands errors and events back to the caller exactly as they were
read off the wire. This should be changed to hand back an additional four bytes
with the full 32-bit sequence number. For compatibility with XCBGenericReply and
Xlib's xReply/xEvent/xError, I'd like to add this new field after the raw bytes.https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/28xv crashed at _xcb_map_remove (list=0x828d9c0, key=2818) at xcb_list.c:892019-02-17T20:27:56ZBugzilla Migration Userxv crashed at _xcb_map_remove (list=0x828d9c0, key=2818) at xcb_list.c:89## Submitted by Martin Mokrejs
Assigned to **xcb mailing list dummy**
**[Link to original bug (#36716)](https://bugs.freedesktop.org/show_bug.cgi?id=36716)**
## Description
Hi,
I found a core file of my xv (image viewer) crash. ...## Submitted by Martin Mokrejs
Assigned to **xcb mailing list dummy**
**[Link to original bug (#36716)](https://bugs.freedesktop.org/show_bug.cgi?id=36716)**
## Description
Hi,
I found a core file of my xv (image viewer) crash. I looks XCB is at fault and not the xv:
Core was generated by `xv ../file.png'.
Program terminated with signal 11, Segmentation fault.
```
#0 _xcb_map_remove (list=0x828d9c0, key=2818) at xcb_list.c:89
89 xcb_list.c: No such file or directory.
in xcb_list.c
(gdb) where
#0 _xcb_map_remove (list=0x828d9c0, key=2818) at xcb_list.c:89
#1 0xb73acafe in poll_for_reply (c=0x828dc40, request=<value optimized out>, reply=0xbfb04c8c, error=0xbfb04cec) at xcb_in.c:297
#2 0xb73acf17 in xcb_wait_for_reply (c=0x828dc40, request=2818, e=0xbfb04cec) at xcb_in.c:377
#3 0xb763db85 in _XReply (dpy=0x828d018, rep=0xbfb04d30, extra=0, discard=1) at xcb_io.c:533
#4 0xb7623425 in XAllocColor (dpy=0x828d018, cmap=32, def=0xbfb04de0) at GetHColor.c:48
#5 0x08068bfa in screen_init (pic24=0xb7147008 '?' <repeats 200 times>..., wide=1123, high=666) at xvimage.c:140
#6 Pic24ToXImage (pic24=0xb7147008 '?' <repeats 200 times>..., wide=1123, high=666) at xvimage.c:2190
#7 0x080695af in CreateXImage () at xvimage.c:1735
#8 0x08050fbc in openPic (filenum=<value optimized out>) at xv.c:2917
#9 0x080529a8 in openFirstPic () at xv.c:3657
#10 mainLoop () at xv.c:3776
#11 0x08055f15 in main (argc=2, argv=0xbfb05f04) at xv.c:1037
(gdb) bt full
#0 _xcb_map_remove (list=0x828d9c0, key=2818) at xcb_list.c:89
cur = 0x828d9c0
#1 0xb73acafe in poll_for_reply (c=0x828dc40, request=<value optimized out>, reply=0xbfb04c8c, error=0xbfb04cec) at xcb_in.c:297
head = <value optimized out>
#2 0xb73acf17 in xcb_wait_for_reply (c=0x828dc40, request=2818, e=0xbfb04cec) at xcb_in.c:377
cond = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}
reader = {request = 2818, data = 0xbfb04c50, next = 0x0}
prev_reader = <value optimized out>
widened_request = <value optimized out>
ret = 0x0
#3 0xb763db85 in _XReply (dpy=0x828d018, rep=0xbfb04d30, extra=0, discard=1) at xcb_io.c:533
error = 0x0
c = 0x828dc40
current = <value optimized out>
__PRETTY_FUNCTION__ = "_XReply"
#4 0xb7623425 in XAllocColor (dpy=0x828d018, cmap=32, def=0xbfb04de0) at GetHColor.c:48
status = <value optimized out>
rep = {type = 0 '\000', pad1 = 0 '\000', sequenceNumber = 0, length = 1, red = 37824, green = 2066, blue = 0, pad2 = 0, pixel = 3076567184, pad3 = 0, pad4 = 135476064, pad5 = 3216002528}
#5 0x08068bfa in screen_init (pic24=0xb7147008 '?' <repeats 200 times>..., wide=1123, high=666) at xvimage.c:140
check_map = 44041082
check_col = {pixel = 1123, red = 0, green = 0, blue = 0, flags = -80 '\260', pad = -65 '\277'}
ci = 0
i = 0
init_flag = 1
check_gc = 0x829efe8
check_image = <value optimized out>
#6 Pic24ToXImage (pic24=0xb7147008 '?' <repeats 200 times>..., wide=1123, high=666) at xvimage.c:2190
xcol = <value optimized out>
lip = <value optimized out>
pp = <value optimized out>
bperpix = 32
ip = <value optimized out>
i = <value optimized out>
j = <value optimized out>
xim = <value optimized out>
#7 0x080695af in CreateXImage () at xvimage.c:1735
No locals.
#8 0x08050fbc in openPic (filenum=<value optimized out>) at xv.c:2917
pinfo = {pic = 0xb7147008 '?' <repeats 200 times>..., w = 1123, h = 666, type = 1, r = '\000' <repeats 255 times>, g = '\000' <repeats 255 times>, b = '\000' <repeats 255 times>, normw = 1123, normh = 666,
frmType = 0, colType = 0, fullInfo = "PNG, 24 bit truecolor, non-interlaced. (125056 bytes)", '\000' <repeats 74 times>, shrtInfo = "1123x666 PNG", '\000' <repeats 115 times>,
comment = 0x828d9b0 "Comment::Created with GIMP\n", exifInfo = 0x0, exifInfoSize = 0, numpages = 1, pagebname = '\000' <repeats 63 times>}
i = <value optimized out>
filetype = <value optimized out>
freename = 1
frompipe = 0
frompoll = 0
fromint = 0
killpage = 0
oldeWIDE = 0
oldeHIGH = 0
oldpWIDE = 0
oldpHIGH = 0
oldCXOFF = 0
oldCYOFF = 0
oldCWIDE = 0
oldCHIGH = 0
wascropped = 0
tmp = <value optimized out>
fullname = <value optimized out>
filename = "/home/XXXXXX/file.png\000mm\221\221\221\221\266\266\266\266\332\332\332\332\377\377\377\377\000\000\000\000$$$$HHHHmmmm\221\221\221\221\266\266\266\266\332\332\332\332\377\377\377\377\000\000\000\000$$$$HHHHmmmm\221\221\221\221\266\266\266\266\332\332\332\332\377\377\377\377\000\000\000\000$$$$HHHHmmmm\221\221\221\221\266\266\266\266\332\332\332\332\377\377\377\377\000\000\000\000$$$$HHHHmmmm\221\221\221\221\266\266\266\266\332\332\332\332\377\377\377\377", '\000' <repeats 32 times>, '$' <repeats 32 times>...
#9 0x080529a8 in openFirstPic () at xv.c:3657
i = 0
#10 mainLoop () at xv.c:3776
---Type <return> to continue, or q <return> to quit---
i = <value optimized out>
#11 0x08055f15 in main (argc=2, argv=0xbfb05f04) at xv.c:1037
i = <value optimized out>
ecdef = {pixel = 9148853, red = 35584, green = 39168, blue = 46336, flags = 7 '\a', pad = -65 '\277'}
rootReturn = 125
parentReturn = 0
children = 0x829d068
numChildren = 122
(gdb)
```
I am on a Gentoo Linux with x11-misc/xcb-2.4, x11-base/xorg-server-1.9.2.902, x11-base/xorg-drivers-1.9, x11-proto/xextproto-7.1.2, and regarding the application itself it is media-gfx/xv-3.10a-r15.
```
$ ldd /usr/bin/xv
linux-gate.so.1 => (0xffffe000)
libz.so.1 => /lib/libz.so.1 (0xb7794000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb767d000)
libm.so.6 => /lib/libm.so.6 (0xb7657000)
libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0xb761c000)
libpng14.so.14 => /usr/lib/libpng14.so.14 (0xb75f7000)
libtiff.so.5 => /usr/lib/libtiff.so.5 (0xb7590000)
libc.so.6 => /lib/libc.so.6 (0xb7436000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb741c000)
libdl.so.2 => /lib/libdl.so.2 (0xb7418000)
/lib/ld-linux.so.2 (0xb77dc000)
libjbig.so => /usr/lib/libjbig.so (0xb740b000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7407000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7401000)
$
```https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/27missing main loop integration API2019-02-16T19:41:29ZBugzilla Migration Usermissing main loop integration API## Submitted by Havoc Pennington
Assigned to **xcb mailing list dummy**
**[Link to original bug (#29657)](https://bugs.freedesktop.org/show_bug.cgi?id=29657)**
## Description
To use XCB nicely with a main loop instead of threads, ...## Submitted by Havoc Pennington
Assigned to **xcb mailing list dummy**
**[Link to original bug (#29657)](https://bugs.freedesktop.org/show_bug.cgi?id=29657)**
## Description
To use XCB nicely with a main loop instead of threads, I think the following are missing.
1. a way to see if any events or replies are buffered (like XPending, but no IO). Used in the "prepare" and "check" steps of GLib main loop for example. Ideally, separate xcb_has_events and xcb_has_replies perhaps. Errors are events if treated as events and replies if checked.
2. a way to "read from socket into internal queue without returning any events or replies". Used in GLib "check" step for example, followed by the XPending type thing.
3. a way to "partially flush with a single write() call" - xcb_partial_flush?
Then in something like GTK, you would have:
* a GSource for the event queue, similar to current Xlib one. Uses current
xcb_poll_for_event in dispatch(), but uses the new API for prepare and check.
Can also poll on writability and do the "xcb_partial_flush" if socket is writeable, so we never get requests that remain unsent if the main loop runs.
* a GSource that lets you add a callback to invoke when a specific reply arrives. This would need to do "read() just once from socket" in its check(), and then xcb_poll_for_reply
Right now the source that nonblockingly auto-flushes in main loop is not possible, and the source that does a callback when a specific reply arrives I don't think is possible either. (without threads, that is.)https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/26xcb_ext.c: get rid of global lock in get_lazyreply2019-02-16T19:41:25ZBugzilla Migration Userxcb_ext.c: get rid of global lock in get_lazyreply## Submitted by Ian Osgood `@iano`
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#10166)](https://bugs.freedesktop.org/show_bug.cgi?id=10166)**
## Description
There is a global lock that must be acquired any time a...## Submitted by Ian Osgood `@iano`
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#10166)](https://bugs.freedesktop.org/show_bug.cgi?id=10166)**
## Description
There is a global lock that must be acquired any time an extension request is used, which protects a clause which only needs protection at the initialization of the extension in a process. We should come up with a lockless design for this logic.
Version: 1.0https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/24make: don't know how to make man/xcb_*. Stop2019-02-16T19:41:19ZBugzilla Migration Usermake: don't know how to make man/xcb_*. Stop## Submitted by Stephen Fisher
Assigned to **xcb mailing list dummy**
**[Link to original bug (#87127)](https://bugs.freedesktop.org/show_bug.cgi?id=87127)**
## Description
When building libxcb-1.11 on NetBSD 6.1.5, I receive this...## Submitted by Stephen Fisher
Assigned to **xcb mailing list dummy**
**[Link to original bug (#87127)](https://bugs.freedesktop.org/show_bug.cgi?id=87127)**
## Description
When building libxcb-1.11 on NetBSD 6.1.5, I receive this error:
make: don't know how to make man/xcb_*. Stop
Compilation succeeds with gmake (gnu make), but autotools programs are supposed to work with standard (in this case, BSD) make in distributed packages. This line must be non-standard Makefile syntax:
BUILT_MAN_PAGES = man/xcb_*
from src/Makefile.am
Version: 1.11https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/23`explicit` is a C++11 keyword, add to _cplusplus_annoyances (with patch)2019-02-16T19:41:15ZBugzilla Migration User`explicit` is a C++11 keyword, add to _cplusplus_annoyances (with patch)## Submitted by Jochen Keil
Assigned to **xcb mailing list dummy**
**[Link to original bug (#74080)](https://bugs.freedesktop.org/show_bug.cgi?id=74080)**
## Description
Created attachment 92810
Patch for c_client.py to fix cpp ke...## Submitted by Jochen Keil
Assigned to **xcb mailing list dummy**
**[Link to original bug (#74080)](https://bugs.freedesktop.org/show_bug.cgi?id=74080)**
## Description
Created attachment 92810
Patch for c_client.py to fix cpp keywords & lookup error
As said in the summary, `explicit` is a C++11 keyword, which makes (at least) xkb.h fail when included in C++11 sources.
Attached is a fix for this ("explicit" => "_explicit" dictionary entry in _cplusplus_annoyances).
However, it's unfortunately not done with updating the dict, some lookups for `field.c_type_name` will now fail. Hence, the reverse cpp keyword lookup.
**Attachment 92810**, "Patch for c_client.py to fix cpp keywords & lookup error":
[xcb.patch](/uploads/a02aad4910197f94a826438c5269717a/xcb.patch)https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/22Explain in the tutorial that core fonts are discouraged2019-02-16T19:41:10ZBugzilla Migration UserExplain in the tutorial that core fonts are discouraged## Submitted by Dan Cecile
Assigned to **xcb mailing list dummy**
**[Link to original bug (#43050)](https://bugs.freedesktop.org/show_bug.cgi?id=43050)**
## Description
The "Basic Graphics Programming" tutorial for XCB includes a ...## Submitted by Dan Cecile
Assigned to **xcb mailing list dummy**
**[Link to original bug (#43050)](https://bugs.freedesktop.org/show_bug.cgi?id=43050)**
## Description
The "Basic Graphics Programming" tutorial for XCB includes a section on fonts and text (http://www.x.org/releases/X11R7.5/doc/libxcb/tutorial/index.html#font). Unfortunately, this part of the tutorial uses server-side, core fonts whose use is discouraged.
This section of the tutorial should be removed, replaced with an Xft section, or at least annotated with a warning that Xft provides better font and text support than the old core fonts system.
For example, the "Fonts in X11" documentation (http://www.x.org/releases/X11R7.5/doc/fonts/fonts.html) says, "While X.Org will continue to maintain the core fonts system, toolkit authors are encouraged to switch to Xft as soon as possible."https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/21connect api calls missing (auth and create fd)2019-02-16T19:41:07ZBugzilla Migration Userconnect api calls missing (auth and create fd)## Submitted by bug..@..zi.org
Assigned to **xcb mailing list dummy**
**[Link to original bug (#33163)](https://bugs.freedesktop.org/show_bug.cgi?id=33163)**
## Description
currently there is a api for connecting with a xcb_auth_i...## Submitted by bug..@..zi.org
Assigned to **xcb mailing list dummy**
**[Link to original bug (#33163)](https://bugs.freedesktop.org/show_bug.cgi?id=33163)**
## Description
currently there is a api for connecting with a xcb_auth_info_t structure but there is no nice api to actually get the structure.
there should be a api like:
xcb_auth_info_t *xcb_get_auth_info(const char *display);
int xcb_create_fd(const char *display);
why: I'm developing a module for ulatencyd that observes the local x server to detect the current program in focus. As the daemon has root privileges, he can't connect to X easily. To obtain the cookie the module needs to fork and drop to the user uid to obtain the cookie and use it with:
xcb_connect_to_display_with_auth_info
As no api is available, i had to copy a lot of xcb code to accomplish this.https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/20want scatter-gather I/O in some protocol stubs2019-02-16T19:41:03ZBugzilla Migration Userwant scatter-gather I/O in some protocol stubs## Submitted by Jamey Sharp `@jamey`
Assigned to **Josh Triplett**
**[Link to original bug (#5962)](https://bugs.freedesktop.org/show_bug.cgi?id=5962)**
## Description
For performance reasons, protocol request stubs that accept va...## Submitted by Jamey Sharp `@jamey`
Assigned to **Josh Triplett**
**[Link to original bug (#5962)](https://bugs.freedesktop.org/show_bug.cgi?id=5962)**
## Description
For performance reasons, protocol request stubs that accept variable-length data
should have an alternate version available that accepts arrays of struct iovec.
See the "Vendor Requests in GLX" thread on the XCB mailing list, from May 2005,
for what we decided to do about this.https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/18xcb_send_event() reads beyond end of argument / is hard to use correctly2019-02-16T19:40:59ZBugzilla Migration Userxcb_send_event() reads beyond end of argument / is hard to use correctly## Submitted by Uli Schlachter `@psychon`
Assigned to **xcb mailing list dummy**
**[Link to original bug (#99946)](https://bugs.freedesktop.org/show_bug.cgi?id=99946)**
## Description
https://bugreports.qt.io/browse/QTBUG-56518 is...## Submitted by Uli Schlachter `@psychon`
Assigned to **xcb mailing list dummy**
**[Link to original bug (#99946)](https://bugs.freedesktop.org/show_bug.cgi?id=99946)**
## Description
https://bugreports.qt.io/browse/QTBUG-56518 is about valgrind warnings that occur in Qt. The code in question does basically:
xcb_unmap_notify_event_t event;
set all fields of event;
xcb_send_event(c, false, root, mask, &event);
The problem here is that sizeof(event) is 16 while xcb_send_event() expects 32 bytes of event data. So the argument needs to be "something bigger". This is quite unintuitive and it seems like everyone using xcb_send_event() is getting this wrong. (I would claim that I know may way around XCB and I did not know this!)
Can there be a version of xcb_send_event() which gets a length argument? Are there any other ideas on how this could be made safer or more obvious?https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/17Allow protocol stubs to be inlined2019-02-16T19:40:54ZBugzilla Migration UserAllow protocol stubs to be inlined## Submitted by Jamey Sharp `@jamey`
Assigned to **Josh Triplett**
**[Link to original bug (#6687)](https://bugs.freedesktop.org/show_bug.cgi?id=6687)**
## Description
A substantial size and speed improvement can probably be obtai...## Submitted by Jamey Sharp `@jamey`
Assigned to **Josh Triplett**
**[Link to original bug (#6687)](https://bugs.freedesktop.org/show_bug.cgi?id=6687)**
## Description
A substantial size and speed improvement can probably be obtained by generating
'extern inline' copies of request and reply functions in the auto-generated
header files produced by c-client.xsl. The reply functions especially should
result in no instructions after inlining; GCC already tail-call optimizes them
into just a 'jmp' instruction, at least on x86.https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/161.9.3: Compiling with 1.9 installed fails, old libraries linked, xcb_send_fd ...2019-02-16T19:40:52ZBugzilla Migration User1.9.3: Compiling with 1.9 installed fails, old libraries linked, xcb_send_fd undefined## Submitted by mar..@..io.org
Assigned to **xcb mailing list dummy**
**[Link to original bug (#72057)](https://bugs.freedesktop.org/show_bug.cgi?id=72057)**
## Description
Solaris 11 SPARC 64, Sun Studio 12.3 compiler
Have libxc...## Submitted by mar..@..io.org
Assigned to **xcb mailing list dummy**
**[Link to original bug (#72057)](https://bugs.freedesktop.org/show_bug.cgi?id=72057)**
## Description
Solaris 11 SPARC 64, Sun Studio 12.3 compiler
Have libxcb 1.9 previously installed in /usr/local.
Compiling up 1.9.3:
CC=cc -xtarget=ultra -m64 -xcode=pic32
CXX=CC -xtarget=ultra -m64 -xcode=pic32
F77=f77 -xtarget=ultra -m64 -xcode=pic32
LDFLAGS=-L/usr/local/lib -R/usr/local/lib
GNUMAKE=/usr/local/bin/gmake
EGREP=/usr/xpg4/bin/egrep
AUTOCONF=/usr/local/bin/autoconf
AUTOMAKE=/usr/local/bin/automake
ACLOCAL=/usr/local/bin/aclocal
AUTOHEADER=/usr/local/bin/autoheader
LIBTOOL=/usr/local/bin/libtool
LIBTHREAD=-lthread
LTLIBTHREAD=-lthread
LIBMULTITHREAD=-lthread
LTLIBMULTITHREAD=-lthread
CLASSPATH=/usr/local/java
XML_CATALOG_FILES=/usr/local/share/xml/catalog.xml
XML_CATALOG_FILE=/usr/local/share/xml/catalog.xml
XMLCATALOG=/usr/local/bin/xmlcatalog
ITSTOOL=/usr/local/bin/itstool
MAKE=/usr/local/bin/gmake
GETOPT=/usr/local/bin/getopt
XMLLINT=/usr/local/bin/xmllint
XSLTPROC=/usr/local/bin/xsltproc
M4=/usr/local/bin/m4
BISON=/usr/local/bin/bison
FLEX=/usr/local/bin/flex
CPPFLAGS=-I/usr/local/include
LINT=lint -m64 -xcode=pic32 -err=warn -h -errchk -v -errfmt=macro
BUILD_DOCS=yes
PLUGINDIR=/usr/local/lib/sasl2
DB_LIB=-L/usr/local/lib -R/usr/local/lib -ldb-4
DB_HEADER=db_185.h
LDLAGS=-L/usr/local/include -R/usr/local/lib
PERL=/usr/local/bin/perl
INSTALL=/usr/local/bin/ginstall
LD_RUN_PATH=/usr/local/lib:/lib/64:/usr/lib/64:/lib:/usr/lib
XMLTO=/usr/local/bin/xmlto
LIBS=-lintl -liconv
CAIRO_LIBS=-L/usr/local/lib -lcairo
CFLAGS=-I/usr/local/include
PERLCC=cc -xtarget=ultra -m64 -xcode=pic32 -xc99
PERLLD=cc -xtarget=ultra -m64 -xcode=pic32 -xc99
PYTHON=/usr/local/bin/python
cd /var/tmp
rm -rf /xcb libxcb-1.9.3
untgz /usr/local/src/x11/libxcb-1.9.3.tar.gz
cd libxcb-1.9.3
mkdir /xcb
./autogen.sh
./configure --prefix=/xcb \
--disable-silent-rules \
--with-doxygen=/usr/local/bin/doxygen
gmake
gmake install
libtool: install: warning: relinking `libxcb-dri3.la'
libtool: install: (cd /var/tmp/libxcb-1.9.3/src; /bin/sh /var/tmp/libxcb-1.9.3/libtool --tag CC --mode=relink cc -xtarget=ultra -m64 -xcode=pic32 -v -I/usr/local/include -I/usr/local/include -I/usr/local/include -version-info 0:0:0 -no-undefined -L/usr/local/lib -R/usr/local/lib -o libxcb-dri3.la -rpath /xcb/lib dri3.lo libxcb.la -lsocket -lintl -liconv )
libtool: relink: cc -xtarget=ultra -m64 -xcode=pic32 -G -z defs -h libxcb-dri3.so.0 -o .libs/libxcb-dri3.so.0.0.0 .libs/dri3.o -R/xcb/lib -R/usr/local/lib -L/usr/local/lib -L/xcb/lib -lxcb -lXau -lXdmcp -lsocket -lintl -lc -liconv -lc -xtarget=ultra -m64
Undefined first referenced
symbol in file
xcb_send_fd .libs/dri3.o
xcb_get_reply_fds .libs/dri3.o
ld: fatal: symbol referencing errors. No output written to .libs/libxcb-dri3.so.0.0.0
libtool: install: error: relink `libxcb-dri3.la' with the above command before installing it
gmake[3]: *** [install-libLTLIBRARIES] Error 1
gmake[3]: Leaving directory `/var/tmp/libxcb-1.9.3/src'
It's not until I delete all of the libxcb 1.9 files in the /usr/local tree that libxcb 1.9.3 will link and install cleanly.
If 1.9.3 needs to link with its new libraries to install properly, the -L/xcb/lib needs to come first, before the customer supplied LDFLAGS are used. The 1.9 libraries in /usr/local mess it up.
host:/xcb/lib root# nm libxcb.so | grep fd
[76] | 62568| 176|FUNC |LOCL |0 |11 |read_fds
[42] | 53088| 144|FUNC |LOCL |0 |11 |set_fd_flags
[476] | 55536| 296|FUNC |GLOB |0 |11 |xcb_connect_to_fd
[555] | 66800| 56|FUNC |GLOB |0 |11 |xcb_get_reply_fds
[874] | 60312| 232|FUNC |GLOB |0 |11 |xcb_send_fd
Version: 1.9.3https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/15AttributeError: 'SimpleType' object has no attribute 'is_event'2019-02-16T19:40:48ZBugzilla Migration UserAttributeError: 'SimpleType' object has no attribute 'is_event'## Submitted by Milav
Assigned to **xcb mailing list dummy**
**[Link to original bug (#109269)](https://bugs.freedesktop.org/show_bug.cgi?id=109269)**
## Description
Created attachment 143052
The Installation Sequence of libxcb
H...## Submitted by Milav
Assigned to **xcb mailing list dummy**
**[Link to original bug (#109269)](https://bugs.freedesktop.org/show_bug.cgi?id=109269)**
## Description
Created attachment 143052
The Installation Sequence of libxcb
Hello Friends,
This is Milav Soni From Teq Diligent.
I downloaded libxcb-1.13 and try to cross-compile for ARM.
When I run make command it gives following error.
File "./c_client.py", line 440, in _c_type_setup
if field.type.is_event:
AttributeError: 'SimpleType' object has no attribute 'is_event'
The configuration is run correctly.
I attached the configuration file which i have enter.
I attached the make command result which i have enter.
Please help me to sort out this problem.
Thank You
**Attachment 143052**, "The Installation Sequence of libxcb":
[xcb_config_status](/uploads/bcf60b588706dc137858d3c9ff4ca207/xcb_config_status)
Version: 1.13https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/12passing lists with variadic sized types to requests looks complicated and err...2019-02-17T20:21:40ZBugzilla Migration Userpassing lists with variadic sized types to requests looks complicated and error prone## Submitted by Daniel Martin
Assigned to **Daniel Martin**
**[Link to original bug (#70956)](https://bugs.freedesktop.org/show_bug.cgi?id=70956)**
## Description
While working on the serialization of requests in my rewrite - yeah...## Submitted by Daniel Martin
Assigned to **Daniel Martin**
**[Link to original bug (#70956)](https://bugs.freedesktop.org/show_bug.cgi?id=70956)**
## Description
While working on the serialization of requests in my rewrite - yeah,
finally - I've found a problem in the currently generated code. I
haven't tested it, but the code doesn't look right. It should be possible to workaround it, but imho this shouldn't be the way those lists are handled.
Requests (with the affected lists in brackets) are:
xinput:XIChangeHierarchy - ['changes']
xinput:XISelectEvents - ['masks']
xkb:SetDeviceInfo - ['leds']
xkb:SetGeometry - ['properties', 'colors', 'shapes', 'outlines']
xkb:SetMap - ['types', 'syms']
xproto:SetFontPath - ['font']
Let's pick xproto:SetFontPath. One shouldn't need to use a font
server, but it's an easy example:
request : http://cgit.freedesktop.org/xcb/proto/tree/src/xproto.xml#n3556
var.type: http://cgit.freedesktop.org/xcb/proto/tree/src/xproto.xml#n3416
The variadic type becomes the structure:
```
typedef struct xcb_str_t {
uint8_t name_len;
}
```
There's no note on the list of characters 'name', which would need to
be used as font path in this case and there's no way to attach such a
string to the structure.
The request takes the font paths as:
` const xcb_str_t *font`
then within the request 'xcb_set_font_path()' the list of font paths becomes part of the 'struct iovec xcb_parts[]' for serialization:
` xcb_parts[4].iov_base = (char *) font;`
and the length gets calculated:
```
for(i=0; i<font_qty; i++) {
xcb_tmp_len = xcb_str_sizeof(xcb_tmp);
xcb_parts[4].iov_len += xcb_tmp_len;
xcb_tmp += xcb_tmp_len;
}
```
The length calculation (including xcb_str_sizeof()) looks good. But, it's just one xcb_parts[] to serialize the font paths, so the xcb_str_t list (the font parameter) already has to be seriallized as there's only one iov_base pointing to it. That means one has to setup and pass something like this as *font:
(Note: Those are just examples, not tested, just to make the problem obvious.)
```
char path0[] = "/foo/bar0";
char path1[] = "/foo/bar1";
char *font = malloc(2*sizeof(xcb_str_t) + strlen(path0) + strlen(path1));
font[0] = strlen(path0);
memcpy(font[1], path0, strlen(path0));
font[strlen(path0)] = strlen(path1);
memcpy(font[strlen(path0)+1], path1, strlen(path1));
xcb_set_font_path (conn, 2, (xcb_str_t*)font);
```
or like this (possible, because 'name_len' is an uint8_t):
```
char font[] =
{/* name_len */ 9, /* name */ '/', 'f', 'o', 'o', '/', 'b', 'a', 'r', '0',
/* name_len */ 9, /* name */'/', 'f', 'o', 'o', '/', 'b', 'a', 'r', '1'};
xcb_set_font_path (conn, 2, (xcb_str_t*)font[0]);
```
The last example may not look that bad. But, imagine a more complex structure having more fields, different types, even fields behind lists. They'd be a mess to setup.
My solution would be an additional type/structure for such variadic types if they show up in a request, which don't hide the variadic parts:
```
typedef struct xcb_str_request_t {
uint8_t name_len;
char *name;
}
```
With that one could setup the font paths much more easy:
```
char path0[] = "/foo/bar0";
char path1[] = "/foo/bar1";
xcb_str_request_t font[2];
font[0].name_len = strlen(path0);
font[0].name = path0;
font[1].name_len = strlen(path1);
font[1].name = path1;
xcb_set_font_path(conn, 2, &font);
```
To serialize this list, it would be necessary to iterate over the list (as it's done atm.) and to adjust the 'struct iovec xcb_parts[]' and the index within dynamically, so we end up having an xcb_parts[] for every xcb_str_request_t and the 'name' list within. But, from my pov that's easy to do when generating the code - much more easy and less error prone than setting up a memory block and filling it with data on the application side.
I hope I didn't missed something important and I hope that I could describe the problem properly.https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/11Use readv to refill input queue during large reply reads2019-02-16T19:40:33ZBugzilla Migration UserUse readv to refill input queue during large reply reads## Submitted by Jamey Sharp `@jamey`
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#7183)](https://bugs.freedesktop.org/show_bug.cgi?id=7183)**
## Description
When XCB reads the header of a response that turns out ...## Submitted by Jamey Sharp `@jamey`
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#7183)](https://bugs.freedesktop.org/show_bug.cgi?id=7183)**
## Description
When XCB reads the header of a response that turns out to be a >4kB reply, it
currently does one big read to get the rest of the reply, and then goes back to
doing another read to fill the input buffer. For a small optimization, it should
instead use readv to request both reads simultaneously.https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/10Compiler warning from xkb.h on 32bit system2019-02-17T20:14:38ZBugzilla Migration UserCompiler warning from xkb.h on 32bit system## Submitted by Gatis Paeglis
Assigned to **xcb mailing list dummy**
**[Link to original bug (#71837)](https://bugs.freedesktop.org/show_bug.cgi?id=71837)**
## Description
xkb.h:118:5: warning: this decimal constant is unsigned on...## Submitted by Gatis Paeglis
Assigned to **xcb mailing list dummy**
**[Link to original bug (#71837)](https://bugs.freedesktop.org/show_bug.cgi?id=71837)**
## Description
xkb.h:118:5: warning: this decimal constant is unsigned only in ISO C90 [enabled by default]
It comes from:
```
typedef enum xcb_xkb_control_t {
XCB_XKB_CONTROL_GROUPS_WRAP = 134217728,
XCB_XKB_CONTROL_INTERNAL_MODS = 268435456,
XCB_XKB_CONTROL_IGNORE_LOCK_MODS = 536870912,
XCB_XKB_CONTROL_PER_KEY_REPEAT = 1073741824,
XCB_XKB_CONTROL_CONTROLS_ENABLED = 2147483648
} xcb_xkb_control_t;
```
appending "u" to
```
XCB_XKB_CONTROL_PER_KEY_REPEAT = 1073741824u,
XCB_XKB_CONTROL_CONTROLS_ENABLED = 2147483648u
```
make the warning go away.