Returns raw byte counts that have been read or written to the
xcb_connection_t.
I found it very useful when developing a high level widget toolkit, to
track down inefficient/sub-optimum code that generates a lot of X
protocol traffic.
Signed-off-by: Sam Varshavchik <mrsam@courier-mta.com>
I have a GTK application which occasionally crashes with an "interrupted
system call" g_message from gdk. After a lot of debugging, I've found
that the call to recvmsg in _xcb_in_read occasionally fails with EINTR,
and instead of retrying the system call, xcb would just shut down the
connection.
This change makes _xcb_in_read treat EINTR the same as it would treat
EAGAIN; it returns 1 and libX11 ends up calling xcb_poll_for_event
again (from what I have understood).
I have spoken with a few people who think recvmsg failing with EINTR in
this case shouldn't ever happen, and I don't know enough to agree or
disagree with that. In case anyone wants to dig further and try to
figure out why the recvmsg call sometimes fails with EINTR, here's the
backtrace from inside of _xcb_in_read where that happened:
Thread 1 "beanbar" hit Breakpoint 1, _xcb_in_read (c=c@entry=0x55ecbe4aba80) at xcb_in.c:1059
1059 fprintf(stderr, "Hello World am %s:%i, errno is %s\n", __FILE__, __LINE__, strerror(errno));
(gdb) bt
0 0x00007fa48fa48639 in _xcb_in_read (c=c@entry=0x55ecbe4aba80) at xcb_in.c:1059
1 0x00007fa48fa489d8 in poll_for_next_event (c=0x55ecbe4aba80, queued=queued@entry=0) at xcb_in.c:352
2 0x00007fa48fa48a3d in poll_for_next_event (queued=0, c=<optimized out>) at xcb_in.c:722
3 0x00007fa48fa48a3d in xcb_poll_for_event (c=<optimized out>) at xcb_in.c:722
4 0x00007fa4908d1b7e in poll_for_event (dpy=dpy@entry=0x55ecbe4a9730, queued_only=queued_only@entry=0) at xcb_io.c:245
5 0x00007fa4908d1cf0 in poll_for_response (dpy=dpy@entry=0x55ecbe4a9730) at xcb_io.c:303
6 0x00007fa4908d1fed in _XEventsQueued (mode=2, dpy=0x55ecbe4a9730) at xcb_io.c:363
7 0x00007fa4908d1fed in _XEventsQueued (dpy=dpy@entry=0x55ecbe4a9730, mode=mode@entry=2) at xcb_io.c:344
8 0x00007fa4908c3d47 in XPending (dpy=0x55ecbe4a9730) at Pending.c:55
9 0x00007fa493cadbc7 in () at /usr/lib/libgdk-3.so.0
10 0x00007fa49234d08a in g_main_context_prepare () at /usr/lib/libglib-2.0.so.0
11 0x00007fa49234d6e6 in () at /usr/lib/libglib-2.0.so.0
12 0x00007fa49234d8ae in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
13 0x00007fa4938b920e in g_application_run () at /usr/lib/libgio-2.0.so.0
14 0x000055ecbc820af4 in main (argc=1, argv=0x7ffd06238098) at src/main.c:190
Signed-off-by: Martin Dørum <martid0311@gmail.com>
If any flags are specified in a call to xcb_take_socket,
they should only be applied to replies for requests sent
after that function returns (and until the socket is
re-acquired by XCB).
Previously, they would also be incorrectly applied to the
reply for the last request sent before the socket was taken.
For instance, in this example program the reply for the
GetInputFocus request gets discarded, even though it was
sent before the socket was taken. This results in the
call to retrieve the reply hanging indefinitely.
static void return_socket(void *closure) {}
int main(void)
{
Display *dpy = XOpenDisplay(NULL);
xcb_connection_t *c = XGetXCBConnection(dpy);
xcb_get_input_focus_cookie_t cookie = xcb_get_input_focus_unchecked(c);
xcb_flush(c);
uint64_t seq;
xcb_take_socket(c, return_socket, dpy, XCB_REQUEST_DISCARD_REPLY, &seq);
xcb_generic_error_t *err;
xcb_get_input_focus_reply(c, cookie, &err);
}
In practice, this has been causing intermittent KWin crashes when
used in combination with the proprietary NVIDIA driver such as
https://bugs.kde.org/show_bug.cgi?id=386370 since when Xlib fails to
retrieve one of these incorrectly discarded replies it triggers
an IO error.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Matching xcbgen changes, add support having a ListType which contains
file descriptors. Use this to send a variable number of FDs to the
server, including when the list size is not fixed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
For when we have a variable-sized field followed by a fixed field, make
sure we do not serialise non-wire fields.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Support for the xinput extension is complete now,
as far as I can tell.
According to our discussion on the list, we enable it now.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Using the mesa vulkan driver, if you acquire an image from a
swapchain using a finite timeout (x11_acquire_next_image_poll_x11),
it will occasionally lock, calling xcb_poll_for_special_event in
a loop until the timeout expires.
Call _xcb_in_read() once from the polling functions for special
events and replies, in the same way as xcb_poll_for_event.
Signed-off-by: David McFarland <corngood@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
_xcb_open does not check strdup's return value for NULL if launchd suport
was configured.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Signed-off-by: Uli Schlachter <psychon@znc.in>
eventstruct allows to use events as part of requests.
This is, e.g., needed by xcb_input_send_extension_event.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
xcb contains an xml-definition for the GenericEvent extension
but this extension was neither generated nor built.
This patch enables optional building of the GenericEvent extension
with configure option --enable-ge
By default, the GenericEvent extension is not built.
Normally this is not needed by application programs
because there is implicit support for the GE-extension
for the specific events built with this extension.
But it may be useful for X-protocol analyzers and stuff like that.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
replace the complicated symboltable lookup for sumof expr
by accessing the lenfield of the expr-object.
This requires the corresponding patch for xcb/proto
which sets the lenfield accordingly.
This should be OK because for official releases we define
that dependency in the build system.
For getting versions off the HEAD of the git repo, it should
be obvious that xcb/proto and xcb/libxcb have to be updated together.
I have tested this patch and it generates exactly the same code
as before.
Tested-by: Christian Linhart <chris@demorecorder.com>
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Found by clang -Wdocumentation:
./xcbext.h:271:11: warning: parameter 'e' not found in the function
declaration [-Wdocumentation]
* @param e Location to store errors in, or NULL. Ignored for un...
^
./xcbext.h:271:11: note: did you mean 'error'?
* @param e Location to store errors in, or NULL. Ignored for un...
^
error
./xcbext.h:283:11: warning: parameter 'e' not found in the function
declaration [-Wdocumentation]
* @param e Location to store errors in, or NULL. Ignored for un...
^
./xcbext.h:283:11: note: did you mean 'error'?
* @param e Location to store errors in, or NULL. Ignored for un...
^
error
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Makes style match the @param names in autogenerated headers and makes
clang -Wdocumentation stop complaining about all of them:
./xcb.h:523:11: warning: parameter 'display:' not found in the function
declaration [-Wdocumentation]
* @param display: A pointer to the display number.
^~~~~~~~
./xcb.h:523:11: note: did you mean 'display'?
* @param display: A pointer to the display number.
^~~~~~~~
display
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Some systems (e.g. OpenBSD) have a rather small default socket send buffer
size of 4KB. The result is that sending requests with a largish payload
requires serveral writev(2) system calls. Make sure the socket send buffer
is at least 64KB such that we're likely to succeed with a single system
call for most requests. A similar change was made to the xtrans code
some time ago.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
Pads should not be serialized/deserialized to maintain
ABI compatibility when adding explicit align pads.
Therefore this pad switches off serialization of pads
unless it is enforced by serialize=true in the xml-definition
of that pad
Signed-off-by: Christian Linhart <chris@demorecorder.com>
If a list is preceded by an align-pad, then
accessor for the end-iterator returned a wrong
value.
Reason: the length of the align-iterator was added
to a pointer of list-member type. Therefore, the length
was multiplied by the size of the list-member type,
due to C pointer arithmetic rules.
This has looked like the following, e.g., in
xcb_randr_get_crtc_transform_pending_params_end:
i.data = ((xcb_render_fixed_t *) prev.data) + ((-prev.index) & (4 - 1)) + (R->pending_nparams);
This bug was introduced with the following commit:
http://cgit.freedesktop.org/xcb/libxcb/commit/?id=4033d39d4da21842bb1396a419dfc299591c3b1f
The fix handles this by casting to char* before adding the align,
and then casting the result to the member type.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
instead of using the lower bits of the pointer address.
This fixes a bug reported by Peter Hutterer in off-list communication
back in June 2015.
This requires the alignment-checker patches in xcb/proto.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
We've released 1.11.1 and new libX11 wants that or better. git master
will suffice, so bump the version number ahead of 1.11 branch.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Handle align-pads when generating an end-function
in the same way as handling them when generating
an accessor or iterator function.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
and make it disabled by default with an EXPERIMENTAL warning
reason: this feature is unfinished and we want to have flexibility for
ABI/API changes, while still being able to make a release soon
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Consider the following:
- Two threads are calling xcb_wait_for_special_event() and xcb_wait_for_reply()
concurrently.
- The thread doing xcb_wait_for_reply() wins the race and poll()s the socket for
readability.
- The other thread will be put to sleep on the special_event_cond of the special
event (this is done in _xcb_conn_wait() via the argument
xcb_wait_for_special_event() gives it).
- The first thread gets its reply, but does not yet receive any special event.
In this case, the first thread will return to its caller. On its way out, it
will call _xcb_in_wake_up_next_reader(), but that function cannot wake up
anything since so far it did not handle xcb_wait_for_special_event().
Thus, the first thread stays blocked on the condition variable and no thread
tries to read from the socket.
A test case demonstrating this problem is available at the bug report.
Fix this similar to how we handle this with xcb_wait_for_reply():
The function wait_for_reply() adds an entry into a linked list of threads that
wait for a reply. Via this list, _xcb_in_wake_up_next_reader() can wake up this
thread so that it can call _xcb_conn_wait() again and then poll()s the socket.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252
Signed-off-by: Uli Schlachter <psychon@znc.in>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
All functions calling _xcb_conn_wait() must make sure that waiting
readers are woken up when we read a reply or event that they are waiting
for. xcb_wait_for_special_event() did not do so. This adds the missing
call to_xcb_in_wake_up_next_reader().
Fixes deadlock when waiting for a special event and concurrently
processing the display connection queue in another thread.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252
Tested-by: Thomas Daede <bztdlinux@gmail.com>
Tested-by: Clément Guérin <geecko.dev@free.fr>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this patch, the following code caused an endless loop in send_fds(),
because the queue of FDs to send was eventually full, but _xcb_out_flush_to()
didn't make any progress, since there was no request to send:
while (1) { xcb_send_fd(conn, dup(some_fd)); }
Fix this by sending a sync when flushing didn't make any progress. That way we
actually have something to send and can attach the pending FDs.
Because send_fds() can now send requests, the code in
xcb_send_request_with_fds64() has to be changed. It has to call send_fds()
before it establishes a good sequence number for the request it wants to send.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Doing xcb_send_fd(), xcb_send_request() is racy. If two threads do this at the
same time, they could mix up their file descriptors. This commit makes it
possibly to fix this race by providing a single function which does everything
that is needed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Two threads trying to send fds at the same time could interfere. To guarantee a
correct ordering, we have to use correct locking. The code in send_fds() missed
one case: If there was another thread already writing requests, we slept on the
"done with writing" condition variable (c->out.cond). This would allow other
threads to re-acquire the iolock before us and could cause fds to be sent out of
order.
To fix this, at the beginning of send_fds() we now make sure that no other
thread is already writing requests. This is what prepare_socket_request() does.
Additionally, it gets the socket back in case xcb_take_socket() was called,
which is a good thing, too, since fds are only sent with corresponding requests.
The API docs for xcb_send_fd() says "After this function returns, the file
descriptor given is owned by xcb and will be closed eventually".
Let the implementation live up to its documentation. We now also close fds if fd
passing is unavailable (!HAVE_SENDMSG) and when the connection is in an error
state.
(This also does sneak in some preparatory functions for follow-up commits and
thus does things in a more complicated way than really necessary.)
Signed-off-by: Uli Schlachter <psychon@znc.in>
(This does not change doxygen's output or warnings).
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
While XCB uses 64-bit sequence number internally, it only exposes
"unsigned int" so that, on 32-bit architecture, Xlib based applications
may see their sequence number wrap which causes the connection to the X
server to be lost.
Expose 64-bit sequence number from XCB API so that Xlib and others can
use it even on 32-bit environment.
This implies the following API addition:
xcb_send_request64()
xcb_discard_reply64()
xcb_wait_for_reply64()
xcb_poll_for_reply64()
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71338
Reviewed-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
In nroff, \n is a macro that "Interpolates number register x" (where x
is the character following the \n sequence), thus the man page currently
prints 0 instead of \n" in several lines, leading to output such as:
printf("The _NET_WM_NAME atom has ID %u0, reply->atom);
It needs to be escaped here, as \\n, as is done in other examples in
this man page already.
https://bugs.freedesktop.org/show_bug.cgi?id=90231
Reported-by: Stefan Merettig
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The name can be understood from the type of S already.
For examples, look for 'S->' in xkb.c or xinput.c.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
Reviewed-by: Rémi Cardona <remi@gentoo.org>
It is implied already inside the function by the `void` argument.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
Matt Turner
Sam Varshavchik
A. Wilcox
Martin Dørum
Jon Turney
Alan Coopersmith
Eduardo Sánchez Muñoz
Uli Schlachter
Erik Kurzinger
Daniel Stone
Christian Linhart
David McFarland
Tobias Stoeckmann
Thomas Klausner
Mark Kettenis
Jaya Tiwari
Adam Jackson
Michel Dänzer
Ran Benita