On Solaris 10 and later, the pthread functions are directly in libc,
and libpthread only has metadata to redirect calls from it to the
libc functions.
On Solaris 9 and older (no longer supported), libc contained its own
thread stubs that libpthread then overrode.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This tutorial example only handles XCB_EXPOSURE and XCB_KEY_RELEASE
events and ignores everything else. Thus, there is no point in asking
for more kinds of events.
A while ago, I ported this tutorial to x11rb [1]. Recently, I received a
pull request [2] removing these unnecessary event masks. This commit is
thus only partially by me and the 'issue' was originally found by the
author of [2].
[1]: https://github.com/psychon/x11rb/blob/master/x11rb/examples/tutorial.rs
[2]: https://github.com/psychon/x11rb/pull/754
Signed-off-by: Uli Schlachter <psychon@znc.in>
Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent
fall-outs, when they contain space.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Syncs the invocation of configure with the one from the server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This fixes https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/53
The issue was that libxcb expected to get a reply based on the request_expected
variable, but a reply would never arrive because the request was never actually
written. To resolve this, a separate request_expected_written variable is
added.
The c->in request counters are uint64_t, and can realistically go over
2**32 over a lifetime of a client. The c->in->replies map however uses
unsigned int keys and the passed request numbers are silently truncated.
I haven't analyzed in depth what happens what it wraps around but it's
probably nothing good.
The only user of the xcb_list.c map code is c->in->replies, so just
change it to use uint64_t keys.
Reviewed-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Ran Benita <ran@unusedvar.com>
The reason strings returned by the server don't all include a newline,
so make sure we add one to avoid confusing clients. Xlib used to do
this before it delegated that work to libxcb.
Fixes#34
Signed-off-by: Julien Cristau <jcristau@debian.org>
Using get_expr_fields() is only needed in case we are doing things that
can span multiple types easily, e.g. when deciding what data to pass via
function parameters and so on.
In _c_serialize_helper_list_field() we are building function body, so
acquiring field names via get_expr_field_names() is enough.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
There are at least two bugs in the previous implementation:
- If an early iovec is partially written, there can be a gap of missing
data (as a later iovec will be started before the early iovec is
completed).
- If a late iovec returns WSAEWOULDBLOCK, *vector and *count are not
updated, leading to a re-send of the entire request.
Move the *vector update into the send() loop to update piecemeal as
individual iovecs are sent.
Example program that demonstrates the issue (this program should run
forever after these bugs have been fixed):
#include <stdio.h>
#include <stdlib.h>
#include "xcb.h"
// Non-cryptographic random number generator from http://burtleburtle.net/bob/rand/smallprng.html
// because Microsoft's random number generators either have a too small RAND_MAX or are too slow
typedef struct ranctx { uint32_t a; uint32_t b; uint32_t c; uint32_t d; } ranctx;
static uint32_t ranval(ranctx *x);
static void raninit(ranctx *x, uint32_t seed);
#define MAX_PROP_LEN (128 * 1024)
int main(int argc, char *argv[]) {
uint32_t seed = 0x12345678;
if (argc > 1) {
seed = strtoul(argv[1], NULL, 0);
}
ranctx ran;
raninit(&ran, seed);
xcb_connection_t *c = xcb_connect(NULL, NULL);
if (!c || xcb_connection_has_error(c)) {
printf("Cannot connect to $DISPLAY\n");
return 1;
}
const xcb_setup_t *setup = xcb_get_setup(c);
char *buf = malloc(MAX_PROP_LEN + 8); // plus a bit of slack so we can run random values off the end
if (!buf) {
printf("oom\n");
return 1;
}
for (uint32_t i=0; i < (MAX_PROP_LEN + 3) / 4; i++) {
((uint32_t *)buf)[i] = ranval(&ran);
}
xcb_window_t win = xcb_generate_id(c);
xcb_create_window(c, 0, win, xcb_setup_roots_iterator(setup).data[0].root, 0, 0, 1, 1, 0,
XCB_WINDOW_CLASS_INPUT_ONLY, 0, 0, NULL);
printf("Created window 0x%X\n", win);
for (;;) {
xcb_flush(c);
xcb_generic_event_t *ev = xcb_poll_for_event(c);
if (ev) {
if (ev->response_type == 0) {
xcb_generic_error_t *err = (xcb_generic_error_t *)ev;
printf("Unexpected X Error %d\n", err->error_code);
printf(" Sequence %d\n", err->sequence);
printf(" Resource ID 0x%X\n", err->resource_id);
printf(" Opcode: %d.%d\n", err->major_code, err->minor_code);
return 1;
}
printf("Unexpected X Event %d\n", ev->response_type);
return 1;
}
uint32_t siz = ranval(&ran) % MAX_PROP_LEN + 1;
xcb_change_property(c, XCB_PROP_MODE_REPLACE, win, XCB_ATOM_STRING, XCB_ATOM_STRING, 8, siz, buf);
}
return 0;
}
#define rot(x,k) (((x)<<(k))|((x)>>(32-(k))))
static uint32_t ranval(ranctx *x) {
uint32_t e = x->a - rot(x->b, 27);
x->a = x->b ^ rot(x->c, 17);
x->b = x->c + x->d;
x->c = x->d + e;
x->d = e + x->a;
return x->d;
}
static void raninit(ranctx *x, uint32_t seed) {
uint32_t i;
x->a = 0xf1ea5eed, x->b = x->c = x->d = seed;
for (i = 0; i<20; ++i) {
(void)ranval(x);
}
}
Signed-off-by: Peter Harris <pharris@opentext.com>
Notable changes: Protect include of unistd.h (and other POSIX headers).
Use SOCKET (which is larger than int) and closesocket (because close is
not compatible) for sockets. Use <stdint.h>'s intptr_t instead of the
non-portable ssize_t.
Signed-off-by: Peter Harris <pharris@opentext.com>
xcb_auth.c:135:14: warning: this statement may fall through [-Wimplicit-fallthrough=]
addr += 12;
~~~~~^~~~~
xcb_auth.c:138:5: note: here
case AF_INET:
^~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Somewhat belatedly given the last update was in xcb-proto 1.13 in 2017...
Quoting @smcv from https://bugs.debian.org/921069:
>>>
libxcb-dri3 version 1.13 appears to have added new symbols without increasing
the minor ABI version in its -version-info. This will break anything that
compares libraries by their version info to decide which one is newer.
The Steam Runtime uses libraries' major/minor/micro ABI version info (in this
case 0.0.0) to decide whether to use the system copy of a library or the copy
in the Steam Runtime, depending on which one is newer (#921026). We can
work around this by adding a versioned dependency on libxcb-dri3-0 and
deleting the copy from the Steam Runtime, but this isn't a particularly
scalable solution.
>>>
It causes errors like this when running make check:
check_public.c:40:24: error: too many arguments for format [-Werror=format-extra-args]
40 | fail_unless(success, "unexpected parse failure %sfor '%s'", test_string[test_type], name);
Closes: https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/49
Tested-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Ran Benita <ran@unusedvar.com>
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>