There could be no upper limit on the length of a path according
to POSIX, therefore these macros may not be defined at all on
some systems (such as GNU Hurd). There is however a limit on
sizeof(struct sockaddr_un.sun_path), so use it.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libxcb/-/merge_requests/65>
This only covers the ones in the pre-written code. There are many more
suggested in the generated code, which will require changing the generator
and will thus be handled separately.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libxcb/-/merge_requests/64>
Nothing was defining __solaris__ on Solaris in current build setup, and
it's not needed on Solaris 10 (released 2005) and later, which has
stdint.h. (Solaris 2.6 - 9 had inttypes.h, but no stdint.h.)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libxcb/-/merge_requests/64>
The UTF-8 quotes can appear in man pages etc as well, not only C code.
For example, in xcb_composite_redirect_subwindows.3:
xcb_composite_redirect_subwindows - Redirect all current and future
children of ‘window’
Note that window is quoted by a pair of UTF-8 single quotes.
Closes: #72
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libxcb/-/merge_requests/60>
Some people apparently use non-utf8 locales and this caused errors when
xcb-proto started using some "fancy" quote marks. Fix this by always
using utf8 encoding.
Fixes: https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/72
Signed-off-by: Uli Schlachter <psychon@znc.in>
If the compiler knows of a better implementation for counting the number
of bits set in a word for the target CPU, let it use that, instead of the
classic algorithm optimized for PDP-6.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
check_public.c: In function ‘parse_display_pass’:
check_public.c:32:32: error: passing argument 1 of ‘putenv’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
32 | putenv("DISPLAY=");
| ^~~~~~~~~~
In file included from check_public.c:4:
/usr/include/stdlib.h:148:19: note: expected ‘char *’ but argument is of type ‘const char *’
148 | extern int putenv(char *);
| ^~~~~~
check_public.c:57:16: error: passing argument 1 of ‘putenv’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
57 | putenv("DISPLAY=");
| ^~~~~~~~~~
/usr/include/stdlib.h:148:19: note: expected ‘char *’ but argument is of type ‘const char *’
148 | extern int putenv(char *);
| ^~~~~~
check_public.c: In function ‘parse_display_fail’:
check_public.c:73:32: error: passing argument 1 of ‘putenv’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
73 | putenv("DISPLAY=");
| ^~~~~~~~~~
/usr/include/stdlib.h:148:19: note: expected ‘char *’ but argument is of type ‘const char *’
148 | extern int putenv(char *);
| ^~~~~~
check_public.c:99:16: error: passing argument 1 of ‘putenv’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
99 | putenv("DISPLAY=");
| ^~~~~~~~~~
/usr/include/stdlib.h:148:19: note: expected ‘char *’ but argument is of type ‘const char *’
148 | extern int putenv(char *);
| ^~~~~~
check_public.c: In function ‘public_suite’:
check_public.c:244:16: error: passing argument 1 of ‘putenv’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
244 | putenv("DISPLAY=");
| ^~~~~~~~~~
/usr/include/stdlib.h:148:19: note: expected ‘char *’ but argument is of type ‘const char *’
148 | extern int putenv(char *);
| ^~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Merge request !30 broke compilation on Windows by introducing unbalanced
curly braces. This change restores the previous behavior on Windows:
only TCP is supported.
This updates the included xcb-proto to the newly required 1.16.
As explained in issue #70, this is a quick workaround, not the
long-term fix for this problem.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Take into account c_need_sizeof when evaluating
xcb_protocol_request_t.count
Incorrect xcb_protocol_request_t.count causes a segmentation fault when
calling functions:
- xcb_randr_set_monitor{_checked}
- xcb_input_change_feedback_control{_checked}
- xcb_input_change_device_control{_unchecked}
Steps to reproduce:
Call xcb_randr_set_monitor() with valid arguments
OBSERVED RESULT
Segmentation fault
```
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x780
at 0x4852925: memmove (in /usr/libexec/valgrind/vgpreload_memcheck-
amd64-linux.so)
by 0x486967C: memcpy (string_fortified.h:29)
by 0x486967C: send_request (xcb_out.c:59)
by 0x486967C: send_request (xcb_out.c:46)
by 0x486967C: xcb_send_request_with_fds64 (xcb_out.c:338)
by 0x48699FC: xcb_send_request (xcb_out.c:359)
by 0x4891F11: xcb_randr_set_monitor_checked (randr.c:5350)
```
EXPECTED RESULT
Function returns cookie
Amend: 77b594f958
Signed-off-by: Ilya Pominov <ipominov@astralinux.ru>
If DISPLAY starts with / or unix:, do not check for anything but a full
filesystem socket path. In particular, abstract AF_UNIX sockets and TCP
sockets will not be used in this case. Also be stricter about parsing
the screen part of /path.screen displays, and bail out after all stat()
errors other than ENOENT.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
When combined with xorg/lib/libxtrans!7, this allows CVE-2020-25697 to
be mitigated by placing the AF_UNIX socket in a secure directory on the
filesystem.
This enables HAVE_LAUNCHD unconditionally and deletes the configure
switch.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
If the function implementing xcb_connect is called directly with a
custom xcb_auth_info_t then checking that the screen in $DISPLAY
is valid is skipped.
Reported by chohag AT jtan DOT com
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Nothing checks for the STDC_HEADERS flag this set, and all supported
systems have C89 compatible headers now.
Clears autoconf warnings of:
configure.ac:93: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:93: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:93: the top level
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
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>
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>
(Also remove unnecessary parens around the condition).
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
This works for all python>=2.6, which is what configure requires.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
c_client.py:2: 'from xml.etree.cElementTree import *' used; unable to detect undefined names
c_client.py:3: 'basename' imported but unused
c_client.py:9: 'time' imported but unused
c_client.py:1437: local variable 'list_obj' is assigned to but never used
c_client.py:1745: local variable 'varfield' is assigned to but never used
c_client.py:2050: local variable 'length' is assigned to but never used
c_client.py:2416: local variable 'R_obj' is assigned to but never used
c_client.py:2441: local variable 'S_obj' is assigned to but never used
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
The results are not used, and the function doesn't have side effects.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
Added accessor functions for requests the same way they were added for
structs,events and replies.
Lists for replies have accessor functions now.
Signed-off-by: Jaya Tiwari <tiwari.jaya18@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
Comment from the Reviewer Christian Linhart:
I have tested your patch after fixing the issues with the patch-format.
It looks good:
* only adds new functions, and does not modify existing functions.
Therefore it is API and ABI compatible.
* adds accessors for varsized-stuff in requests.
This is needed for server-side XCB and may be useful for implementing X11-protocol proxies.
Parametrized structs contain paramref expressions which
refer to the value of a field defined in the context
where the struct is used.
Implementing the parametrized structs turned out
to be somewhat easier than previously thought
because the generator already had some support for type-parametrization
because this is needed when case or bitcase refers to fields outside
of the switch.
So I decided to go with the flow and to implement the solution
which best fits the current implementation.
I did the following:
* I provided a way to specify fieldref with an explicitely given type:
This resulted in <paramref type="CARD8>fieldname</paramref>
A paramref is just a fieldref with an explicit type.
The type is necessary because there is no local field of that
name where the type can be derived from.
* then I tested it and made several changes in the generator
such that it really works.
Basically the generated code is as follows:
* The parameter appears on the parameter list of the
sizeof-function of the parametrized struct.
When that function gets called, an appropriate argument is supplied.
* The parameter also appears as an additional member of the iterator-struct
for the iterator of lists of that parametrized struct.
This way, the next-function can get the value of that parameter from the iterator.
When the iterator is created, this iterator-member is set accordingly.
* When the paramref appears in the length-expression of a list, then
the parameter appears on the parameterlist of the "length" and "end" functions.
When these functions get called, an appropriate argument is supplied.
Some comments:
* I did not implement inline structs.
This would probably have been more complicated, and at least some additional effort.
But that can be implemented later if needed.
(Inline structs could probably use some code from switch-case/bitcase which is already kind of
an inlined struct but one has to be careful not to break the functionality
of switch-case/bitcase. Support for inline structs inside lists must probably
be implemented from scratch...)
* The paramref expression refers to a field of the same name in the struct/request/...
where it is used.
So it is not possible to pass the value of arbitrary fields or even expressions
to the parametrized struct.
This would have been possible with the previously discussed <typearg>.
That can be added later, if needed.
( Wont be too complicated )
* So this is pretty much like the proposal from Ran Benita.
changes for V2 of this patch, according to suggestions from Ran Benita:
* replace map with list comprehension
because map returns an iterator instead of a list from Python 3 on,
so it cannot be added to a list anymore.
* removed "self" parameter of function additional_params_to_str
and accessed the variable additional_params from the outer
function directly.
changes for V2 of this patch:
* adapt to revision 2 of patchset ListInputDevices
* style fixes for similar things that Ran Benita has found in my previous patches
Message-ID: <54574397.4060000@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] parametrized structs implemented
Patch-Set: ParametrizedStruct
Patch-Number: libxcb 1/1
Patch-Version: V3
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Support for listelement-ref needs the following three changes
(in the order as they appear in the patch):
* making the current list-element accessible with the variable
xcb_listelement which is a pointer to the list-element
* supporting lists of simple-type for sumof with a nested expression
* using the variable for resolving a listelement-ref expression
Changes for V2 of this patch:
- adapt to removal of patch "libxcb 2/6" from patchset "ListInputDevices".
Changes for V3 of this patch:
- adapt to V2 of patch "libxcb 5/6" from patchset "ListInputDevices"
Changes for V4 of this patch:
- adapt to revision 2 of the patchset "ListInputDevices"
Message-ID: <545743A0.50907@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] support popcount of a list and associated xml changes
Patch-Set: PopcountList
Patch-Number: libxcb 4/4
Patch-Version: V4
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
The function _c_accessor_get_length had a special case handling
for intermixed var and fixed size fields.
However:
* The implementation of that special case was buggy:
It tried to call a python-dict as a function which causes
Python to abort the program with a stacktrace and error message.
So this code was never used.
* The case it tried to handle is handeled elsewhere in the
meantime: in _c_helper_absolute_name by previous patches
made by me.
Message-ID: <1409845851-38950-3-git-send-email-chris@demorecorder.com>
Patch-Thread-Subject: [Xcb] support popcount of a list and associated xml changes
Patch-Set: PopcountList
Patch-Number: libxcb 3/4
Patch-Version: V1
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Accessors are generally needed for var-sized fields
and fields after var-sized fields.
Generic events can have ver-sized fields.
Therefore they need accessors.
Message-ID: <1409845851-38950-2-git-send-email-chris@demorecorder.com>
Patch-Thread-Subject: [Xcb] support popcount of a list and associated xml changes
Patch-Set: PopcountList
Patch-Number: libxcb 2/4
Patch-Version: V1
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
_c_type_setup is not called for eventcopies anymore:
Reasons:
* the type-setup of an eventcopy would overwrite members of the original
event object such as c_type, ...
* it is needed for the next patch, i.e., generating accessors:
type_setup would create sizeof-etc funtions which called
undefined accessor functions.
Sizeof-functions are generated for compatibility:
Reason:
* Type-setup of eventcopies has previously generated
sizeof-functions for eventcopies.
So, we still need to generate these functions.
These new sizeof-functions simply call the sizeof-function
of the defining event of the eventcopy.
Message-ID: <1409845851-38950-1-git-send-email-chris@demorecorder.com>
Patch-Thread-Subject: [Xcb] support popcount of a list and associated xml changes
Patch-Set: PopcountList
Patch-Number: libxcb 1/4
Patch-Version: V1
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
The loop-variable "sep" is never empty in function
"_c_helper_fieldaccess_expr", after a fix elsewhere.
Therefore I removed the handling of the case of "sep" being empty.
Thanks to Ran Benita for the hint that this can be removed.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <545627C2.3050608@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 9/9
Patch-Version: V1
The function _c_helper_absolute_name was named in
a misleading way.
It computes a C-expression for accessing a field of an xcb-type.
Therefore the name _c_helper_fieldaccess_expr is more appropriate.
Note: Patch 6 of this series has been removed during the review process.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <545627AE.2040200@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 7/9
Patch-Version: V1
Support sumof with a nested expression.
The nested expression is computed for every list-element
and the result of the computation is added to the sum.
This way, sumof can be applied to a list of structs,
and, e.g., compute the sum of a specific field of that struct.
example:
<struct name="SumofTest_Element">
<field type="CARD16" name="foo" />
<field type="CARD16" name="bar" />
</struct>
<struct name="SumofTest_FieldAccess">
<field type="CARD32" name="len" />
<list type="SumofTest_Element" name="mylist1">
<fieldref>len</fieldref>
</list>
<list type="CARD16" name="mylist2">
<sumof ref="mylist1">
<fieldref>bar</fieldref>
</sumof>
</list>
</struct>
generated tmpvar:
int xcb_pre_tmp_1; /* sumof length */
int xcb_pre_tmp_2; /* sumof loop counter */
int64_t xcb_pre_tmp_3; /* sumof sum */
const xcb_input_sumof_test_element_t* xcb_pre_tmp_4; /* sumof list ptr */
generated code:
/* mylist2 */
/* sumof start */
xcb_pre_tmp_1 = _aux->len;
xcb_pre_tmp_3 = 0;
xcb_pre_tmp_4 = xcb_input_sumof_test_field_access_mylist_1(_aux);
for ( xcb_pre_tmp_2 = 0; xcb_pre_tmp_2 < xcb_pre_tmp_1; xcb_pre_tmp_2++) {
xcb_pre_tmp_3 += xcb_pre_tmp_4->bar;
xcb_pre_tmp_4++;
}
/* sumof end. Result is in xcb_pre_tmp_3 */
xcb_block_len += xcb_pre_tmp_3 * sizeof(uint16_t);
changes for V2 of this patch:
* explicitely set the member access operator in the prefix-tuple
passed to function _c_helper_field_mapping.
This enables us to simplify function "_c_helper_absolute_name"
(which will be renamed "_c_helper_fieldaccess_expr" soon)
V3: Changed style and formatting according to suggestions from Ran Benita
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <54562798.8040500@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 5/9
Patch-Version: V3
A sumof-expression now generates explicit code ( for-loop etc )
instead of calling xcb_sumof.
This way, it supports any type which can be added.
Previously, only uint_8 was supported.
Here's an example and the generated code:
xml:
<struct name="SumofTest">
<field type="CARD32" name="len" />
<list type="CARD16" name="mylist1">
<fieldref>len</fieldref>
</list>
<list type="CARD8" name="mylist2">
<sumof ref="mylist1"/>
</list>
</struct>
declaration of tempvars at the start of enclosing function:
int xcb_pre_tmp_1; /* sumof length */
int xcb_pre_tmp_2; /* sumof loop counter */
int64_t xcb_pre_tmp_3; /* sumof sum */
const uint16_t* xcb_pre_tmp_4; /* sumof list ptr */
code:
/* mylist2 */
/* sumof start */
xcb_pre_tmp_1 = _aux->len;
xcb_pre_tmp_3 = 0;
xcb_pre_tmp_4 = xcb_input_sumof_test_mylist_1(_aux);
for ( xcb_pre_tmp_2 = 0; xcb_pre_tmp_2 < xcb_pre_tmp_1; xcb_pre_tmp_2++) {
xcb_pre_tmp_3 += *xcb_pre_tmp_4;
xcb_pre_tmp_4++;
}
/* sumof end. Result is in xcb_pre_tmp_3 */
xcb_block_len += xcb_pre_tmp_3 * sizeof(uint8_t);
This patch is also a preparation for sumof which can access
fields of lists of struct, etc.
V2: Changed style and formatting according to suggestions from Ran Benita
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <54562774.8030306@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 4/9
Patch-Version: V2
This patch provides a mechanism for generating
preparatory code for expressions.
This is e.g. necessary when an expression needs computations
which cannot be done in a C-Expression, like for-loops.
This will be used for sumof expressions but may be useful
elsewhere.
Note: Patch 2 of this series has been removed during the review process.
V2: adapt to changes in previous patches
V3: some style and formatting changes according to suggestions from Ran Benita.
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <54562769.3090405@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 3/9
Patch-Version: V3
Fix _c_helper_absolute_name for fields which cannot be accessed
as a struct/union member but which can be accessed by an
accessor function.
The fix generates calls to the accessor function in these cases.
Example:
<struct name="AbsnameTest">
<field type="CARD32" name="len" />
<list type="CARD8" name="mylist1">
<fieldref>len</fieldref>
</list>
<list type="CARD8" name="mylist2">
<sumof ref="mylist1"/>
</list>
</struct>
The sumof-expression ( <sumof ref="mylist1"/> ) refers to mylist1
which is only acessible by an accessor function.
Previously, sumof was only used inside bitcases,
where such lists are accessible by members of the
deserialized parent struct.
(there is a difference between deserialization of switches
and structs.)
V2 of this patch:
* replaced "!= None" with "is not None" because that's more pythonic.
(according to suggestion from Ran Benita)
V3 of this patch: simplification:
* fixed the recursion in _c_type_setup
so that _c_helper_absolute_name does not need check
a gazillion things as a workaround anymore.
* simplified _c_helper_absolute_name
- remove unneeded check for empty string before
append of last_sep to prefix_str
- removed those if-conditions which are not
needed anymore after fixing the recursion
in _c_type_setup.
- extract functionality for checking whether a field
needs an accessor ( and which type of accessor )
in functions.
(also extracted from _c_accessors)
- rearrange the condition branches and actions for
more readability.
V3 generates exactly the same *.c and *.h files as V2.
V4 of this patch:
* improve formatting as per suggestions of Ran
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <54562758.5090107@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 1/9
Patch-Version: V4
Nested structs which are generated for named case and bitcase
do not get a typename anymore, i.e., they are anonymous structs.
Reasons for this change:
* Prior typenames have caused nameclashes
* Prior typenames introduced names in the global namespace which
did not start with the xcb prefix.
This change is safe with respect to API compatibility because:
I have searched for instances of named bitcases and there's only one place
where they are used, and that's in xkb.xml: reply GetKbdByName.
( no need to search for <case> because it was introduced after the last release )
The reply GetKbdByName is broken in its current form in the xkb.xml anyways,
so it is most probably not used anywhere.
So, my conclusion is that we can safely omit named types for nested structs.
No need for an attribute.
Message-ID: <1409731849-51897-1-git-send-email-chris@demorecorder.com>
Patch-Thread-Subject: Re: [Xcb] names of nested structs of named bitcase/case are prone to nameclashes. Solution?
Patch-Set: NestedStructTypenames
Patch-Number: libxcb 1/1
Patch-Version: V1
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
Fix the alignment computation inside switches which start at
an unaligned pos.
This affects both explicit and implicit align pads.
The alignment offset is derived from the lowest 3 bits of
the pointer to the protocol-data at the start of the switch.
This is sufficient for correcting all alignments up to 8-byte alignment.
As far as I know there is no bigger alignment than 8-byte for the
X-protocol.
Example:
struct InputState, where the switch starts after two 1-byte fields,
which is a 2 byte offset for 4-byte and 8-byte alignment.
The previous problem can be demonstrated when adding a
<pad align="4"/> at the end of case "key".
(Or when finding a testcase which reports the case "valuator" not
at the last position of the QueryDeviceState-reply.
I didn't find such a testcase, so I have used the pad align
as described above.)
V2: patch modified in order to fix bugs which I found when working on the
next issue:
* xcb_padding_offset has to be set 0 when xcb_block_len is set 0
* xcb_padding_offset cannot be "const" therefore
* for unpack and unserialize, the padding_offset must computed
from _buffer instead of from the aux_var.
V3: patch revised according to suggestion by Ran Benita:
* only create and use xcb_padding_offset for switch
Message-ID: <1410298000-24734-1-git-send-email-chris@demorecorder.com>
Patch-Thread-Subject: [Xcb] xinput:QueryDeviceState: full-support: generator and xml-changes
Patch-Set: QueryDeviceState
Patch-Number: libxcb 4/4
Patch-Version: V3
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
This essentially requires to have a correct sizeof-function
for the struct.
This in turn requires a sizeof-function for the switch, too.
Making a sizeof-function for the switch is triggered by
replacing "elif" by "if" in the first change of this patch.
This way, c_need_sizeof is also set to True for switches if appropriate.
The _c_serialize_helper_switch_field function has to support
the context "sizeof":
This is done in the second change of this patch
The third change of this patch fixes an alignment error:
It does not make sense to base the padding on the struct-type
which is generated for switch because this struct does not
represent the protocol. Rather it is the output of deserialization.
( The implicit padding for var-sized fields has other issues, IMHO,
but I am not touching these now...)
The effect on the generated code for the current xml-files
is as follows:
* several additional sizeof-functions are generated
* the fix of the alignment error only changes one place
in the XKB-extension for the GetKbdByName-reply.
This is no problem because that reply in its current form
is broken/unfinished anyways.
Note:
This patch also fixes a problem in the generator when
a fixed-size list is the last field of a case or bitcase.
Message-ID: <1408653356-21191-2-git-send-email-chris@demorecorder.com>
Patch-Thread-Subject: [Xcb] xinput:QueryDeviceState: full-support: generator and xml-changes
Patch-Set: QueryDeviceState
Patch-Number: libxcb 2/3
Patch-Version: V1
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
Program using the xcb sub-modules has indirect compile and runtime
dependency of core xcb. To ensure this out we currently list xcb in
the Requires field of the pkg-config files. While this provides all
the required dependencies for successful compilation this causes
over-linking and hides potential linking miss-use against the xcb modules.
By moving to Requires.private we retain the compilation and runtime
compatibility and avoids any runtime problems.
Cc: Keith Packard <keithp@keithp.com>
Cc: Alan Coopersmith <alan.coopersmith@oracle.com>
References: http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq
References: https://wiki.mageia.org/en/Overlinking_issues_in_packaging
References: http://err.no/personal/blog/2008/Mar/25
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Uli Schlachter <psychon@znc.in>
V2: patch revised according to suggestions from Ran Benita:
* removed blanks before an after parentheses of function-calls or tuples
* replaced if by elif in "if field.type.is_list". ( this fixes old code )
Message-ID: <540B4D17.1080908@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] xinput:QueryDeviceState: full-support: generator and xml-changes
Patch-Set: QueryDeviceState
Patch-Number: libxcb 1/3
Patch-Version: V2
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-By: Ran Benita <ran234@gmail.com>
The documentation doesn't mention it and it's unlikely that a lot of code out
there handles this case correctly. So, instead of returning NULL, let
xcb_get_setup() return a pointer to a static, invalid, all-zero setup
information structure.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There is no technical reason why xcb_get_setup() and xcb_get_file_descriptor()
shouldn't work on non-static error connections. They cannot be used for many
useful things, but at least they work.
This works around bugs in lots of programs out there which assume that
xcb_get_setup() does not return NULL and which just happily dereference the
results. Since xcb_connect() never returns NULL, it's a bit weird that
xcb_get_setup() can do so. xcb_get_file_descriptor() is just modified since this
can be done here equally easily and because the fd isn't closed until the final
xcb_disconnect() on the error connection.
Non-static error connections are connections which entered an error state after
xcb_connect() succeeded. If something goes wrong in establishing a connection,
xcb_connect() will return a static error connection which doesn't have the
fields used here.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The implementation is rather simple:
When a <case> is used instead of a <bitcase>
then operator "==" is used instead of "&" in the if-condition.
So it creates a series of "if" statements
(instead of a switch-case statement in C )
In practice this does not matter because a good
optimizing compiler will create the same code
as for a switch-case.
With this simple implementation we get additional
flexibility in the following forms:
* a case value may appear in multiple case branches.
for example:
case C1 will be selected by values 1, 4, or 5
case C2 will be selected by values 3, 4, or 7
* mixing of bitcase and case is possible
(this will usually make no sense but there may
be protocol specs where this is needed)
details of the impl:
* replaced "is_bitcase" with "is_case_or_bitcase" in all places
so that cases are treated like bitcases.
* In function "_c_serialize_helper_switch": write operator "=="
instead of operator "&" if it is a case.
Originally there was just one. Now that XCB has been integrated with X and
uses the same compiler flags, it is a different story.
Used CFLAGS:
CPPFLAGS............:
CFLAGS..............: -g -O2
Warning CFLAGS......: -Wall -Wpointer-arith AND SO ON FOR 8 lines...
It completely defaces the otherwise excellent output.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Same as all other X modules. The one in libxcb git is removed.
Those files are created during 'make dist'
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Uli Schlachter <psychon@znc.in>
DRI3 requires sendmsg support which is auto-detected. A builder can enable
or disable dri3 feature. If sendmsg function is not available, dri3 cannot
be enabled.
This reverts af8067cbf4 which was done at a time where --enable-dri3
had not been added yet.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a user issues the --enable-dri3 option and sendfds is not available
on the system, the configuration will abort with an error message.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Uli Schlachter <psychon@znc.in>
The first symptom is the help text:
--enable-dri3 Build XCB DRI3 Extension (default: "$sendfds")
The implementation variable $sendfds leaked into the user interface.
Testing the various user inputs:
<nothing> DRI3 is enabled PASS
--enable-dri3 DRI3 is enabled PASS
--enable-dri3=yes DRI3 is enabled PASS
--enable-dri3=no DRI3 is disabled PASS
--disable-dri3 DRI3 is disabled PASS
--enable-dri3=$sendfds DRI3 is disabled FAIL
This patch implements the usual idiom for features that are enabled by
default if the various conditions are met (sendfds is available).
New help text:
--enable-dri3 Build XCB DRI3 Extension (default: auto)
With the additional user input:
--enable-dri3=auto
which is equivalent to providing no input at all.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Uli Schlachter <psychon@znc.in>
These structs are typedef'ed in xproto.h, so in xcb.h these types
(without 'struct') are actually undefined.
GCC reports this as error when building precompiled header.
Signed-off-by: Alexander Mezin <mezin.alexander@gmail.com>
Reviewed-by: Peter Harris <pharris@opentext.com>
They are bloated, don't add anything over the signature, in some cases
duplicate the doxygen comments, and are not integrated with the <doc>
tags in any way. Remove them and cut the generated LOC by half.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Some parts of the man pages (SEE ALSO and ERRORS) are generated by
iterating a Python dict. But the iteration order in a dict is random,
so each build the output is ordered differently. Avoid that by iterating
in sorted order.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
The script adds many fields to the objects coming from xcbgen. To
distinguish them, a c_ prefix is used, but for some it was missing.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
AIX <sys/poll.h> does redefine 'events' to 'reqevents' eventually.
To not have this cause compilation errors, need to include the local
header files after any system header file.
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Documentation was previously unclear that these always return a non-NULL
pointer, and that callers need to check it for error values, instead of
checking for a NULL return value.
Triggered by having to dig through code to answer a user's question on
the #xcb irc channel, since neither of us found it covered in the docs.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Without this patch we end up with invalid C code if we've a
<pad align="n" /> between two variadic lists. Check for such a condition
and take the alignment pad into account.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79808
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
This changes away from hard-coding the /tmp/launch-* path to now
supporting a generic <path to unix socket>[.<screen>] format for
$DISPLAY.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
send_request may only write to out.queue if no other thread is busy
writing to the network (as that thread may be writing from out.queue).
send_request may only allocate request sequence numbers if XCB owns
the socket.
Therefore, send_request must make sure that both conditions are true
when it holds iolock, which can only be done by looping until both
conditions are true without having dropped the lock waiting for the
second condition.
We choose to get the socket back from Xlib first as get_socket_back
has a complicated test and checking for other threads writing is a
simple in-lined check.
This also changes the sequence number checks (64k requests with no
reply, 4M request wrapping) to ensure that both conditions are true
before queueing the request.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Some xcb libraries depend on others; make these dependencies explicit
in the .pc files that are installed.
This change was generated automatically by running 'check-pc-requires -fix'
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
This walks through the .pc.in files and makes sure all of the Requires
lines express sufficient dependency information.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
This avoids having the nested header files also included at the top
level, which is more efficient.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Code can be simplified if the deallocation functions can always be called in
cleanup code. So if you have some code that does several things that can go
wrong, one of which is xcb_connect(), after this change, the xcb_connection_t*
variable can be initialized to NULL and xcb_disconnect() can always be called on
the connection object.
References: http://lists.freedesktop.org/archives/xcb/2013-September/008659.html
Signed-off-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Julien Cristau <jcristau@debian.org>
There are two kind of error connections in XCB. First, if something goes wrong
while the connection is being set up, _xcb_conn_ret_error() is used to return a
static connection in an error state. If something goes wrong later,
_xcb_conn_shutdown() is used to set c->has_error.
This is important, because the static object that _xcb_conn_ret_error() returns
must not be freed, while the dynamically allocated objects that go through
_xcb_conn_shutdown() must obviously be properly deallocated.
This used to work correctly, but in 769acff0da, xcb_disconnect() was made to
ignore all connections in an error state completely. Fix this by only ignoring
the few static error connections that we have.
This was tested with the following hack:
xcb_connection_t *c = xcb_connect(NULL, NULL);
close(xcb_get_file_descriptor(c));
xcb_discard_reply(c, xcb_get_input_focus(c).sequence);
xcb_flush(c);
xcb_disconnect(c);
Valgrind confirms that xcb has a memory leak before this patch that this patch
indeed fixes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Julien Cristau <jcristau@debian.org>
If xcb_connect() fails, it doesn't return NULL. Instead, it always
returns an xcb_connection_t*, and the user should check for errors with
the xcb_connection_has_error() function. What this function does is
check if conn->has_error contains a non-zero error code, and returns it.
If an error did occur, xcb doesn't actually return a full
xcb_connection_t though, it just returns (xcb_connection_t *)
error_code. Since the 'has_error' field is the first, it is still
possible to check conn->has_error.
That last trick was not immediately obvious to me, so add some guiding
comments. This also ensures no one obliviously rearranges the struct.
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
The section number is no longer hard-coded
The left footer is now "X Version 11".
The center footer is the package name with the version, "libxcb 1.9"
The three values above are provided through xorg-macros. They are passed-in
to the python c_client code.
Example of footer (last line, above dotted line)
[...]
AUTHOR
Generated from xproto.xml. Contact xcb@lists.freedesktop.org for cor‐
rections and improvements.
X Version 11 libxcb 1.9 xcb_send_event(3)
------------------------------------------------------------------------------
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
The automake MAN primary requires a hard coded extension to build
man pages. Let's avoid that as the extension number may vary by platform.
Take advantage of the fact that the man directory only contains man pages.
Wildcards are not supported by Automake but it happens to work
sufficiently well here.
Normally xorg build man pages by converting a source .man file to a
target file with the extension number. That would be too many files
in this case.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
The section number is no longer hard-coded, supplied by xorg-macros.
The left footer is now "X Version 11".
The center footer is the package name with the version, "libxcb 1.9"
The man directory is a sibbling to the doc directory. One can build
or clean the man pages without disturbing the library code.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
No content or form changes for the xcb manual or tutorial.
Only the configuration user visible bits change.
Xcb will now have the same configuration options as the 30 other
xorg modules.
Xorg classifies documentation as "user", "developer" or "specifications".
The xcb manual falls under the "developer" category. Developers docs
are never installed under $prefix.
A builder can selectively turn on/off any or all of the categories. He can
also selectively turn on/off any of the many tools used to generate
documentation such as doxygen, xmlto, etc... Each tool has an environment
variable defined such as DOXYGEN.
Other features are available, the user interface and the functionality
is the same on all modules.
--with-doxygen=FILE is replaced with DOXYGEN env variable
--disable-build-docs is replaced with --disable-devel-docs
The new interface displayed with ./configure --help:
--enable-devel-docs Enable building the developer documentation
(default: yes)
--with-doxygen Use doxygen to regenerate documentation (default:
auto)
DOXYGEN Path to doxygen command
DOT Path to the dot graphics utility
The dot tool checking has been added to util-macros in version 1.18.
Refer to the table of existing docs in xorg.
XCB will be added for the doxygen generated API manual.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This is the updated minimum level as referenced in:
http://www.x.org/wiki/Building_the_X_Window_System/#index2h3
Libtool version 2 has been used for several years now. There should be
no surprises.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
No functional changes. Trying to make it clearer.
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
The BASE_CFLAGS variable contains only warnings, just like the XCB
version of CWARNFLAGS. This will result in no changes in the binaries
produced. Xorg was missing -fd for SUNCC so it has been added to util-macros
v 1.18.
Do not get confused with the xorg deprecated CWARNFLAGS variable which
contains an option that is not a warning, -fno-strict-aliasing. This
option, should it be needed, can be added using the XORG_TESTSET_CFLAG
macro.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
XCB has been part of X.Org for a while now. This patch will harmonize the XCB
configuration, using xorg-macros series of macros. It is already used in the
XCB utils packages and is needed to build xcb-proto.
The XORG_DEFAULT_OPTIONS already includes the statement for the silent
rules.
The AC_PROG_CC statement is removed so as not to override AC_PROG_CC_C99
in XORG_DEFAULT_OPTIONS. The effective change is that xcb now uses c99 as
requested.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
With the advent of the Present extension, some events (such as
PresentCompleteNotify) now use native 64-bit types on the wire.
For XGE events, we insert an extra "uint32_t full_sequence" field
immediately after the first 32 bytes of data. Normally, this causes
the subsequent fields to be shifted over by 4 bytes, and the structure
to grow in size by 4 bytes. Everything works fine.
However, if event contains 64-bit extended fields, this may result in
the compiler adding an extra 4 bytes of padding so that those fields
remain aligned on 64-bit boundaries. This causes the structure to grow
by 8 bytes, not 4. Unfortunately, XCB doesn't realize this, and
always believes that the length only increased by 4. read_packet()
then fails to malloc enough memory to hold the event, and the event
processing code uses the wrong offsets.
To fix this, mark any event structures containing 64-bit extended
fields with __attribute__((__packed__)).
v2: Use any(...) instead of True in (...), as suggested by
Daniel Martin.
v3 (Alan Coopersmith): Fix build with Solaris Studio 12.3 by moving the
attribute to after the structure definition.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com> [v1]
Reviewed-by: Josh Triplett <josh@joshtriplett.org> [v1]
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
libxcb 1.9.1 was released from a branch and thus its NEWS entries never made it
into the master branch. The other releases didn't update NEWS.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Cristau <jcristau@debian.org>
As RFC 2292 points out, some platforms (e.g. Darwin 9.8.0) provide
CMSG_FIRSTHDR(msg) which just returns msg.msg_control without first
checking if msg.msg_controllen is non-zero. We need a workaround for
such platforms not to let _xcb_in_read() segfault.
https://bugs.freedesktop.org/show_bug.cgi?id=72253
Signed-off-by: Julien Cristau <jcristau@debian.org>
Sync: Due to commit e6a246e50e62cbcba3 "sync: Change value list param of
CreateAlarm and ChangeAlarm into switch", various symbols disappeared,
for example xcb_sync_{change,create}_alarm_sizeof.
xinput: This extension was updated from version 1.4 to 2.3. This means
that lots of new things are generated. However, this change is
backwards-compatible and thus age gets set to 1.
xkb: In commit 37d0f55392d6 "xkb: Work around alignment problems in
GetNames and GetMap replies", some padding fields were introduced into
structures for which an _unpack() function is generated. This changed
the size of the struct and caused offsets into this struct to change.
https://bugs.freedesktop.org/show_bug.cgi?id=71507
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This reverts commit f4d5b84800.
The version of this struct that the code generator produces breaks the API,
because it gives the fields different (albeit better) names. Thus, we need to
restore the old version of this struct.
Additionally to the revert, this struct is documented as being deprecated. The
replacement was added to xcb-proto.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71502
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Currently, it is not possible to correctly iterate over the replies of
some requests. For example, the list of XIDeviceInfo returned by
the XIQueryDevice request from xinput2 is read as garbage starting from
the second entry.
The culprits are the _sizeof() used by the iterators. In the above case:
int
xcb_input_xi_device_info_sizeof (const void *_buffer /**< */)
{
char *xcb_tmp = (char *)_buffer;
[...]
unsigned int xcb_block_len = 0;
[...]
xcb_block_len += sizeof(xcb_input_xi_device_info_t);
xcb_tmp += xcb_block_len;
/* name */
xcb_block_len += (((_aux->name_len + 3) / 4) * 4) * sizeof(char);
xcb_tmp += xcb_block_len;
[...]
}
The problem here is that `xcb_block_len` is not zero'd right above the
`/* name */` comment, causing `xcb_tmp` to be incremented by
`sizeof(xcb_input_xi_device_info_t)` twice. The returned size is too
large.
https://bugs.freedesktop.org/show_bug.cgi?id=68387
Tested-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This reverts commit 9ae84ad187.
After this patch was merged, there were complaints about it not being a good
idea. Revert this for now until we can agree on this.
References: http://lists.freedesktop.org/archives/xcb/2013-June/008340.html
Signed-off-by: Uli Schlachter <psychon@znc.in>
Conflicts:
src/xcbint.h
A char array on the stack is not guaranteed to have more than byte alignment.
This means that casting it to a 'struct cmsghdr' and accessing its members
may result in unaligned access. This will generate SIGBUS on struct
alignment architectures like OpenBSD/sparc64. The canonical solution is to
use a union to force proper alignment.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Required to expose the structure members in Solaris headers, since it
was an XPG4/UNIX95 addition to the Solaris ABI.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
--disable-sendfds or --enable-sendfds
By default, configure auto-detects based on whether your system
supports sendmsg at all.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Use these instead of computing the values directly so that it might
work on BSD or other non-Linux systems
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This allows apps to peel off certain XGE events into separate queues
for custom handling. Designed to support the Present extension
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-By: Uli Schlachter <psychon@znc.in>
Requests signal which replies will have fds, and the replies report
how many fds they expect in byte 1.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-By: Uli Schlachter <psychon@znc.in>
This uses sendmsg to transmit file descriptors from the application to
the X server
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-By: Uli Schlachter <psychon@znc.in>
Many system headers have warnings when compiled with this flag.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-By: Uli Schlachter <psychon@znc.in>
When new XML files get installed, make sure the C files are regenerated
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-By: Uli Schlachter <psychon@znc.in>
It seems like POLLIN is specified as equivalent to POLLRDNORM | POLLRDBAND. Some
systems (e.g. QNX and HP-UX) take this literaly and have POLLIN defined as the
above bit combination. Other systems (e.g. Linux) have POLLIN as just a single
bit.
This means that if no out-of-band data is available (which should never be the
case), the result of poll() will not fulfil (fd.revents & POLLIN) == POLLIN on
QNX, because the POLLRDBAND bit is not set.
In other words, even though poll() signaled that the fd is readable, xcb would
not read from the file descriptor.
Fix this by checking if any bits from POLLIN are set in the result of poll(),
instead of all of them.
(This change was independently done by seanb@qnx.com as well)
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38001
Acked-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Uli Schlachter <psychon@znc.in>
In commit 8eba8690ad, the API documentation for xcb_poll_for_event() was
fixed to remove an argument that was previously removed in commit 34168ab549.
However, that commit only removed the first line of the documentation, leaving
behind a spurious half-sentence. That commit happened seven years ago and now
finally someone noticed...
Thanks to Benjamin Herr for reporting this on IRC.
v2: Thanks again to Benjamin Herr for noticing that my commit message blamed the
wrong commit.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Don't ignore the files config.h and config.h.in, adjust the pattern to
ignore config.h*. This matches an additional config.h.in~ too.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Tested-By: Ran Benita <ran234@gmail.com>
- Follow the suggestion by libtoolize:
"Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
rerunning libtoolize, to keep the correct libtool macros in-tree.
Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am."
and add the macro and define.
- Create the m4 directory and move acinclude.m4 as xcb.m4 there.
- Ignore the m4 files libtoolize copies into the m4 directory
(m4/l*.m4).
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Tested-By: Ran Benita <ran234@gmail.com>
Remove the generated directory ./autom4te.cache by reusing ./build-aux
as cache directory.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Tested-By: Ran Benita <ran234@gmail.com>
Do not clutter the project directory with generated/copied auxiliary
files, save them in ./build-aux.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Tested-By: Ran Benita <ran234@gmail.com>
Remove a second AC_PREREQ and bump the required autoconf version to
2.60.
Version 2.59c was a testing release, published in April 2006. Version
2.60 was the stable release afterwards, released in June 2006.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Tested-By: Ran Benita <ran234@gmail.com>
This fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=66413
Bug 66413 - libxcb 1.9.1: Fails to build on Arch Linux: \
/home/<user>/install-sh: No such file or directory
Without that patch the search path for `install-sh` will become $HOME
and the `install` target will fail, when DESTDIR doesn't exist in
advance. (occured with automake 1.14 and autoconf 2.69)
Initial patch by: Alain Kalker <a.c.kalker@gmail.com>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Tested-By: Ran Benita <ran234@gmail.com>
Fix Bug 23863 - xcb still checks for xsltproc:
https://bugs.freedesktop.org/show_bug.cgi?id=23863
xsltproc is used to generate the optional html page for `check` results,
only. So, it's not a hard build dependency.
Additionally, use yes/no instead of true/false in the HTML_CHECK_RESULT
variable for consistent output after a configure run.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Do not create pointers in unions for fields of variadic length.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
to get rid of:
warning: 'xcb_align_to' may be used uninitialized in this function
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Peter Harris <pharris@opentext.com>
Fixes Solaris Studio compiler warning:
"xcb_list.c", line 50: warning: old style function definition
and gcc warning:
xcb_list.c: In function '_xcb_map_new':
xcb_list.c:50:11: warning: old-style function definition [-Wold-style-definition]
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
There have not been any big issues with xcb-xkb recently.
Also, Wayland is using xcb-xkb actively, making distributions compile
libxcb with xkb support anyway, so let’s reflect reality :).
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
The generic event structure xcb_ge_event_t has the full_sequence field
at the 32byte boundary. That's why we've to inject this field into GE
events while generating the structure for them. Otherwise we would read
garbage (the internal full_sequence) when accessing normal event fields
there.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
To prevent different threads from stealing the socket from each other the
caller of "xcb_take_socket" must hold a lock that is also acquired in
"return_socket". Unfortunately xcb tries to prevent calling return_socket
from multiple threads and this can lead to a deadlock situation.
A simple example:
- X11 has taken the socket
- Thread A has locked the display.
- Thread B does xcb_no_operation() and thus ends up in libX11's return_socket(),
waiting for the display lock.
- Thread A calls e.g. xcb_no_operation(), too, ends up in return_socket() and
because socket_moving == 1, ends up waiting for thread B
=> Deadlock
This patch allows calling return_socket from different threads at the same time
an so resolves the deadlock situation.
Partially fixes: https://bugs.freedesktop.org/show_bug.cgi?id=20708
v2: fixes additional pthread_cond_wait dependencies,
rework comments and patch description
v3: separate pthread_cond_wait dependencies and unrelated whitespace
change into their own patch, use unsigned for socket_seq
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Ensure that when calculating the size of the incoming response from the
Xserver, we don't overflow the integer used in the calculations when we
multiply the int32_t length by 4 and add it to the default response size.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Adopt a change from xcbgen. With that modification the expression in a
bitcase became a list of expressions to support multiple <enumref> in a
<bitcase>.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
Replace except statement with a PEP-3110 compliant one. This fixes a regression
introduced by c3deeaf714https://bugs.freedesktop.org/show_bug.cgi?id=55690
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
This was found by distcheck. It tried to install src/man/xcb-examples.3 and
src/man/xcb-requests.3, but those files weren't in the distribution.
Fix this by explicitly telling automake to distribute those files.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This fixes a deadlock which was seen in-the-wild with wine.
It could happen that two threads tried to read from the socket at the same time
and one of the thread got stuck inside of poll()/select().
The fix works by making sure that the writing thread doesn't steal the reading
thread's reply.
Debugged-by: Erich Hoover <ehoover@mines.edu>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54671
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allows an application to do a scatter/gather operation on a large
image buffer to avoid the extra memcpy.
Use autoconf to use UIO_MAXIOV where IOV_MAX is not available (and the
POSIX minimum of 16 where neither are available).
Reviewed-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Peter Harris <pharris@opentext.com>
Matches the behaviour of Xlib - if you set DISPLAY to :0.1 but only have
one screen, closes connection and returns error.
This introduces a new connection error code:
XCB_CONN_CLOSED_INVALID_SCREEN
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Allows configure to set defines such as _POSIX_SOURCE in config.h
that affect functions exposed by system headers and get consistent
results across all the source files.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
On FreeBSD MSG_WAITALL on a non-blocking socket fails immediately if less bytes
than were asked for are available. This is different than the behavior on linux
where as many bytes as are available are returned in this case. Other OS
apparently follow the FreeBSD behavior.
_xcb_in_read() is used to fill xcb's read buffer, thus this function will call
recv() with a big length argument (xcb's read buffer is by default 16 KiB
large). That many bytes are highly unlikely to be available in the kernel
buffer.
This means that _xcb_in_read() always failed on FreeBSD. Since the socket was
still signaled as readable by poll(), this bug even resulted in a busy loop.
The same issue is present in read_block(), but here it is slightly different.
read_block() is called when we read the first few bytes of an event or a reply,
so that we already know its length. This means that we should be able to use
MSG_WAITALL here, because we know how many bytes there have to be.
However, that function could busy loop, too, when only the first few bytes of
the packet were sent while the rest is stuck somewhere on the way to us. Thus,
MSG_WAITALL should be removed here, too.
Thanks to Christoph Egger from Debian for noticing the problem, doing all the
necessary debugging and figuring out what the problem was! This patch is 99%
from debian. Thanks for all the work.
This bug was introduced in commit 2dcf8b025b.
This commit also reverts commit 9061ee45b8.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=45776
Signed-off-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
2dcf8b025b was causing some regressions on
darwin, so go back to using read(2) there until I have time to investigate
further.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Unfortunately, commit 31b57676 adding WSACleanup/WSAShutdown on Win32 adds a new use
of error_connection, which was removed in commit 769acff0, applied 5 minutes earlier.
src/xcb_util.c: In function 'xcb_connect_to_display_with_auth_info':
src/xcb_util.c:433:39: error: 'error_connection' undeclared (first use in this function)
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Arvind Umrao <arvind.umrao@oracle.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fix a redefinition problem which shows up when building for _WIN32 and
libXdmcp is installed, so HASXDMAUTH is enabled
It seems this is a special place in xcb as it uses other X11 library headers here
If HASXDMAUTH is defined, include the wrapped windows.h before any header which
includes it unwrapped, to avoid conflicts with types defined in X headers
We need to include config.h and check HASXDMAUTH to avoid an unconditional dependency
on x11proto headers
In file included from install/include/X11/Xdmcp.h:19:0,
from git/xcb/libxcb/src/xcb_auth.c:52:
install/include/X11/Xmd.h:120:14: error: conflicting types for 'INT32'
/usr/i686-pc-mingw32/sys-root/mingw/include/basetsd.h:54:13: note: previous declaration of 'INT32' was here
install/include/X11/Xmd.h:143:15: error: conflicting types for 'BOOL'
/usr/i686-pc-mingw32/sys-root/mingw/include/windef.h:234:17: note: previous declaration of 'BOOL' was here
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
This reverts commit 0e9246def5.
This change caused build failures because <X11/Xdmcp.h> was never
included under any circumstance. This is because the check for
HASXDMAUTH was moved before the inclusion of config.h (via xcbint.h)
which defined it.
Found-by: Tinderbox
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
The alternative is to use these in every WIN32 application which uses xcb. Doing
it this way should be safe, as, according to MSDN, "There must be a call to
WSACleanup for each successful call to WSAStartup. Only the final WSACleanup
function call performs the actual cleanup. The preceding calls simply decrement
an internal reference count"
(We should probably also include ws2_32 in Libs.private for libxcb, as anything
which links with libxcb will also need that, but there seems to be some pkg-config
issues to resolve first...)
v2: Check for errors so WSAStartup()/WSACleanup() uses are balanced
v3: Use same indentation style as surrounding code
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Fix a redefinition problem due to include order which shows up when
building for _WIN32 and libXdmcp is installed, so HASXDMAUTH is enabled
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
WIN32 does not have arpa/inet.h, so do not try to include it unless _WIN32 is
not defined
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41443
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=42304
I have added more xcb connection error states at xcb.h header.
Also I have removed global error_connection variable, and added
an interface that returns connection error state.
TBD:
I will segregate errors states in a separate header file and try to
provide more precise error states, in future. Also I will give patch
for libX11, in that patch xcb_connection_t::has_error will be passed
to default io handler of libX11. This value can then be used for
displaying error messages.
Reviewed-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Arvind Umrao <arvind.umrao@oracle.com>
_xcb_out_flush_to will drop the iolock in pthread_cond_wait allowing
other threads to queue new requests. When this happened,
there would be requests queued for the socket after _xcb_out_flush_to
returned, and xcb_take_socket would throw an assert.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29875
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Imagine two threads:
Thread#1: for(;;) { xcb_get_input_focus_reply(c, xcb_get_input_focus(c), 0); }
Thread#2: for(;;) { xcb_poll_for_event(c); }
Since xcb_poll_for_event() calls _xcb_in_read() directly without synchronizing
with any other readers, this causes two threads to end up calling recv() at the
same time. We now have a race because any of these two threads could get read
the GetInputFocus reply.
If thread#2 reads this reply, it will be put in the appropriate queue and
thread#1 will still be stuck in recv(), although its reply was already received.
If no other reply or event causes this thread to wake up, the process deadlocks.
To fix this, we have to make sure that there is only ever one thread reading
from the connection. The obvious solution is to check in poll_for_next_event()
if another thread is already reading (in which case c->in.reading != 0) and not
to read from the wire in this case.
This solution is actually correct if we assume that the other thread is blocked
in poll() which means there isn't any data which can be read. Since we already
checked that there is no event in the queue this means that
poll_for_next_event() didn't find any event to return.
There might be a small race here where the other thread already determined that
there is data to read, but it still has to wait for c->iolock. However, this
means that the next poll_for_next_event() will be able to read the event, so
this shouldn't cause any problems.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=40372
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Peter Harris <pharris@opentext.com>
Uli's patch is an excellent solution; I just want to keep the new
ALIGNOF macro hidden from XCB's users, as they don't need it to call
XCB.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Some of these systems (eg. Interix on XP) are still in use.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Peter Harris <pharris@opentext.com>
The code previously assumed that everything has to be aligned to a 4 byte
boundary. This assumption is wrong as e.g. the STR struct from xproto shows.
Instead, each type has to be aligned to its natural alignment. So a char doesn't
need any alignment, a INT16 gets aligned to a 2-byte-boundary and a INT32 gets
the old 4 byte alignment.
I'm not 100% sure that this commit is correct, but some quick tests with awesome
and cairo-xcb went well.
This commit causes lots of dead assignments to xcb_align_to since only the last
field's alignment is actually used, but this simplified this patch a lot.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=34037
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Peter Harris <pharris@opentext.com>
When a system is completely offline (no interface has an IP address but 'lo'),
xcb could not connect to localhost via TCP, e.g. connections with
DISPLAY=127.0.0.1:0 fail.
AI_ADDRCONFIG will only return IPv4 addresses if the system has an IPv4
address configured (likewise for IPv6). This also takes place when
resolving localhost (or 127.0.0.0/8 or ::1). Also, as per RFC 3493,
loopback addresses are not considered as valid addresses when
determining whether to return IPv4 or IPv6 addresses.
As per mailing-list discussion on the xcb list started with message
20110813215405.5818a0c1@x200, the AI_ADDRCONFIG flag is there for historical
reasons:
In the old days, the "default on-link" assumption in IPv6 made the flag vey
much indispensable for dual-stack hosts on IPv4-only networks. Without it,
there would be long timeouts trying non-existent IPv6 connectivity. Nowadays,
this assumption has been flagged as historic bad practice by IETF, and hosts
should have been updated to not make it anymore.
Then AI_ADDRCONFIG became mostly cosmetic: it avoids phony "Protocol family
not supported" or "Host unreachable" errors while trying to connect to a dual-
stack mode from a host with no support for source address selection.
Nowadays, on up-to-date systems, this flag is completely useless. Then again,
I understood only the very latest MacOS release is "up-to-date" with this
definition.
If a the path to the xcb python generate libs is
explicitly specified to c_client.py, insert it in
the python path list just after the local dir entry,
rather than appending it to the existing paths.
This keeps a global/distro install of xcb from
overriding a local build of the xcb proto files.
Signed-off-by: James Jones <jajones@nvidia.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Python 3 introduces some language changes that cause issues when running
c_client.py. This also breaks compatibility with Python 2.5 since it does not
support the "as" statement in try/except blocks and does not have reduce() in
the functools package.
The main changes are:
* try/except blocks require `except ... as ...:` to resolve syntactical ambiguity
* map() and filter() return iterators rather than lists in Python 3
* reduce() is now in functools package (and not built-in in Python 3)
* Dictionaries don't have a has_key() method in Python 3
* None and int types can't be directly compared in Python 3
* print() is a statement in Python 3
See http://diveintopython3.org/porting-code-to-python-3-with-2to3.html and
PEP-3110 for details.
Verified on Python 2.6.5 and 3.1.3.
Signed-off-by: David Coles <dcoles@gaikai.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
This function was intended to allow libX11 to fix a multi-threaded hang,
but the corresponding libX11 patch caused single-threaded apps to spin
sometimes. Since I've retracted that patch, this patch has no users and
shouldn't go into a release unless/until that changes.
This reverts commit 2415c11dec.
Conflicts:
src/xcb.h
src/xcb_in.c
Signed-off-by: Jamey Sharp <jamey@minilop.net>
In some circumstances using xcb_poll_for_event is suboptimal because
it checks the connection for new events. This may lead to a lot of
failed nonblocking read system calls.
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Fixes fallback to local connections from Xlib's XOpenDisplay(), which
will try with protocol "unix" if a hostname is specified and tcp fails
(as it usually will now that most OS'es ship with -nolisten tcp enabled).
Also fixes explicitly specifying DISPLAY as "unix/foo:0", which Xlib
previously accepted for Unix domain sockets.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This patch is necessary so xcb reads the payload after the message
for GenericEvents with the 0x80 flag turned on.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Solves compiler warning on Solaris:
"xcb_conn.c", line 304: warning: implicit function declaration: shutdown
Also provides system definition of SHUT_RDWR on Solaris 11.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
"unifdef -UDNETCONN src/xcb_util.c" plus re-indenting code that was
formerly in the else clause after a DECnet check.
DECnet support has been removed from most of the X.Org code base for
several years, and it appears DNETCONN was never defined in XCB.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Solaris Trusted Extensions puts the endpoints for the X server's Unix
domain sockets in a special directory shared from the global zone to
each of the labeled zones, since each labeled zone has a separate /tmp.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Harris <pharris@opentext.com>
Variable new_sockname will leak and sockname will be double freed if
both of the cases shown below are true.
1. realloc succeeds and doesn't return the original pointer
2. calling socket_func fails
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
Reviewed-by: Arnaud Fontaine <arnau@debian.org>
Signed-off-by: Peter Harris <pharris@opentext.com>
Later patches will insert reader_list entries from other entry points.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
This incantation is supposed to be a no-op on earlier automake versions.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
It's possible to call xcb_wait_for_reply more than once for a single
request. In this case we are nice and let reply waiters continue so
that they can notice that the reply is not available
anymore. Otherwise an event waiter could just signal the reply waiter
that got its reply to continue but leave a waiter for an earlier reply
blocked.
Below is an example sequence for reproducing this problem.
thread #1 (XNextEvent)
- waits for events
thread #2 (XSync)
- executes request #2
- waits for reply #2
thread #1
- reads reply #2
- signals waiter of reply #2 to continue
- waits for events
thread #2
- handles reply #2
thread #3 (XCloseDisplay)
- executes request #3
- waits for reply #2
thread #1
- reads reply #3
- nobody is waiting for reply #3 so don't signal
- wait for events
Of course it may be questionable to wait for a reply twice, but XCB
should be smart enough to let clients continue if they choose to do
so.
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Windows' file handles have never been small or consecutive, so Windows'
select has always been implemented the same way as everyone else's poll.
On Windows, FD_SETSIZE is the size of the poll array, not the maximum
SOCKET number.
Signed-off-by: Peter Harris <git@peter.is-a-geek.org>
If lots of requests are send without one causing a reply, xcb can get confused
about the current sequence number of a reply. Document the requirements of an
external socket owner to avoid this problem.
The return_socket callback for xcb_take_socket() originally was supposed to
return the last sequence number used, but the version committed to libxcb never
actually had this signature. This fixes the function's documentation not to
mention this non-existent return value.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
If the initial get_peer_sock_name(getpeername ...) succeeds, the
pointer to allocated memory is overwritten by the later call to
get_peer_sock_name(getsockname ...). Fix that up by freeing
the allocated memory before overwriting the pointer.
Signed-off-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Julien Danjou <julien@danjou.info>
If you discard a sequence number that has multiple responses already
read, this will do more allocations than necessary. But nobody cares
about ListFontsWithInfo.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
This simplifies the critical section of xcb_send_request and fixes a
couple of subtle bugs:
- It's possible for xcb_send_request to need to issue two sync requests
before it can issue the real request. Previously, we counted sequence
numbers as if both were issued, but only one went out on the wire.
- The test for whether to sync at 32-bit sequence number wrap has been
incorrect since we switched to 64-bit sequence numbers internally.
This change means that if the output queue was already full and the
current request is bigger than the output queue, XCB will do one more
write syscall than it did before. But syncs are rare and small requests
are the norm, so this shouldn't be a measurable difference.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
By calling memmove instead of memcpy, and walking the buffer backward
from the end, *_unserialize is safe to use in-place.
Signed-off-by: Peter Harris <pharris@opentext.com>
In support of this, consolidate the two static error_connection
definitions into one so we don't try to free the static out-of-memory
error_connection.
Commit by Josh Triplett and Jamey Sharp.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
If a client calls close(2) on the connection's file descriptor and then
flushes writes, libxcb causes a hang in the client.
Any flush eventually calls _xcb_out_send() with has the following loop:
while(ret && *count)
ret = _xcb_conn_wait(c, &c->out.cond, vector, count);
_xcb_conn_wait(), if built with USE_POLL, gets the POLLNVAL error. It only
checks for POLLIN and POLLOUT though, ignoring the error. Return value is 1,
count is unmodified, leaving us with an endless loop and a client hang.
XTS testcase Xlib3/XConnectionNumber triggers this bug. It creates a display
connection, closes its file descriptor, tries to send a no-op, and then expects
an error.
http://cgit.freedesktop.org/xorg/test/xts/tree/xts5/Xlib3/XConnectionNumber.m
If poll returned POLLHUP or POLLERR, we might see the same result.
If poll returns any event we didn't ask for, this patch causes
_xcb_conn_shutdown() to be invoked and an error returned. This matches the
behaviour if select(2) is used instead of poll(2): select(2) returns -1 and
EBADF for an already closed file descriptor.
I believe this fix both is safe and will handle any similar error. POSIX says
that the only bits poll is permitted to set in revents are those bits that were
set in events, plus POLLHUP, POLLERR, and POLLNVAL. So if we see any flags we
didn't ask for then something has gone wrong.
Patch inspired by earlier proposals from Peter Hutterer and Aaron
Plattner--thanks!
Reported-by: Peter Hutterer <peter.hutterer@who-t.net>
Reported-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Cc: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
Fixes the X Test Suite's XCloseDisplay-6 test, which has this (admittedly
ridiculous) behavior:
1. Create a window w.
2. Open two display connections, dpy1, and dpy2.
3. Grab the server using dpy1.
4. Fork.
5 (child). XSetProperty on w using dpy2.
5 (parent). Verify that no event was recieved on dpy1.
6 (parent). XCloseDisplay(dpy1).
6 (child). Verify that an event was received on dpy2.
It was failing because at step 6 (child), the server had not actually ungrabbed
yet because the file descriptor for dpy1 was still open in the child process.
Shutting down the socket during XCloseDisplay matches the behavior of non-XCB
Xlib, which calls shutdown() from _X11TransSocketDisconnect.
Thanks to Julien Cristau for noticing this.
Signed-off-by: Aaron Plattner <aplattner at nvidia.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Peter Harris <pharris@opentext.com>
This fixes the test case I have so far for Havoc's report that
xcb_request_check hangs.
Rationale: Since we have a void cookie, request_expected can't have been
set equal to this sequence number when the request was sent; it can only
have become equal due to the arrival of an event or error. If it became
equal due to an event then we still need to sync. If it became equal due
to an error, then request_completed will have been updated, which means
we correctly won't sync.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=29599
However, Havoc reports that he can still reproduce the problem, so we
may be revisiting this later.
Reported-by: Havoc Pennington <hp@pobox.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
- API compatibility with valueparam
- request _aux() auxiliary functions
- _serialize() and _unserialize() auxiliary functions
- new data type that allows mixing of fixed and variable size members
launchd: Explicitly search /sbin
Previously, launchd wasn't found if /sbin wasn't in the user's PATH.
https://bugs.freedesktop.org/show_bug.cgi?id=29028
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
I was surprised to see that xinput was not installed. Looking at
configure.ac, it seems that it is disabled by default. Maybe configure
should output the status of the different extensions.
protocol and host are allocated in _xcb_parse_display but ownership of
them is passed to the caller. They have to be freed in
xcb_connect_to_display_with_auth_info.
Signed-off-by: Pauli Nieminen <ext-pauli.nieminen@nokia.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
xcb_parse_display claims that there is no side effects when failing.
That requires _xcb_parse_display to free the memory in failure case.
Signed-off-by: Pauli Nieminen <ext-pauli.nieminen@nokia.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
Support scenarios where host is not set and protocol is. eg:
DISPLAY=tcp/:0
as well as the "inet" and "inet6" alias for "tcp" for compatability
with Xlib
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
This is a regression found by tinderbox in previous commit:
xcb_util.c: In function '_xcb_open':
xcb_util.c:213: error: 'fd' undeclared (first use in this function)
There could be no upper limit on the length of a path according
to POSIX, therefore these macros may not be defined at all on
some systems (such as GNU Hurd).
Signed-off-by: Arnaud Fontaine <arnau@debian.org>
Reviewed-by: Peter Harris <pharris@opentext.com>
Regression found by tinderbox in 89b3485dad
xcb_util.c:31:27: error: sys/syslimits.h: No such file or directory
xcb_util.c: In function '_xcb_open':
xcb_util.c:148: error: 'PATH_MAX' undeclared (first use in this function)
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Since writers must make sure they read as well, threads may have gone to
sleep waiting for the opportunity to read. The writer must wake up one
of those readers or the application can hang.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
xcb_ge_event_t has its length field in the same place that
xcb_generic_reply_t does, so there's no need to cast the generic reply.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Danjou <julien@danjou.info>
_xcb_out_send needs _xcb_conn_wait to store back its progress so it can
be reinvoked to pick up where it left off---but then _xcb_out_send
guarantees that it leaves either an empty output vector or a shut-down
connection, so *its* callers never care how much progress was made.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
Depending on the process file limit, a file descriptor can be larger
than the capacity of fd_set. There is no portable way to create a
large enough fd_set at run-time. So we just fail if the file descriptor
number is too high and poll() is not available.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Julien Danjou <julien@danjou.info>
libxcb's 010e5661 (Fix XDM-AUTHORIZATION-1 (bug #14202)) mistakenly
inverted a few lines of code, making local socket authentication fail on
hpux and Hurd: when getpeername fails, sockname needs to be initialized
by getsockname before its address family can be checked.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
This saves the X11 connection from leaking into children processes.
On Linux, this is fully thread-safe using SOCK_CLOEXEC. On other
systems, there is a small race condition.
Signed-off-by: Julien Danjou <julien@danjou.info>
This function is useful for dynamic language garbage collectors. Frequently
a GC cycle may run before you want to block wainting for a reply.
This function is also marginally useful for libxcb apps that issue
speculative requests (eg. xlsclients).
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Tested-by: Eamon Walsh <efw@eamonwalsh.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
This matches xtrans behaviour in SocketINETConnect, and makes it so apps
don't hang forever if their display dies.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Bugzilla #21992
make -j check fails because the check-local rule gets executed before
the tests actually ran, so CheckLog*.xml doesn't exist.
Signed-off-by: Julien Danjou <julien@danjou.info>
-no-undefined is needed to tell libtool a shared library can be built
on platforms which require all references to be statisfied at link time.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Julien Danjou <julien@danjou.info>
Also replace excessively clever use of bitwise OR with equivalent
addition.
Reported-by: Geoffrey Li <geoffrey@seitopos.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
With this patch, we know use correctly the socket address or peer
address for authentication purpose.
Signed-off-by: Julien Danjou <julien@danjou.info>
Many code was duplicated between xcb_connect_to_display_with_auth_info
and xcb_connect(). We merge both, since the difference is just about the
xcb_auth_info_t pointer being supplied, or not.
Signed-off-by: Julien Danjou <julien@danjou.info>
Local socket connections currently do not work on hurd-i386 because
xcb_auth calls getpeername() on the client socket, but hurd-i386 does
not implement anything in that case (I actually wonder what reasonable
value could be returned). In such case the xcb code does not actually
need the peer name anyway.
Signed-off-by: Julien Danjou <julien@danjou.info>
This fixes a bug where c_client.py wasn't generating *_end functions,
but expected them to exist in order to find the subsequent list's start.
Signed-off-by: Peter Harris <peter.harris@hummingbird.com>
Libraries like Xlib, some XCB language bindings, and potentially others
have a common problem: they want to share the X connection with XCB. This
requires coordination of request sequence numbers. Previously, XCB had an
Xlib-specific lock, and allowed Xlib to block XCB from making requests.
Now we've replaced that lock with a handoff mechanism, xcb_take_socket,
allowing external code to ask XCB for permission to take over the write
side of the socket and send raw data with xcb_writev. The caller of
xcb_take_socket must supply a callback which XCB can call when it wants
the write side of the socket back to make a request. This callback
synchronizes with the external socket owner, flushes any output queues if
appropriate, and then returns the sequence number of the last request sent
over the socket.
Commit by Josh Triplett and Jamey Sharp.
Handoff mechanism inspired by Keith Packard.
This allows optimizing adjacent pending replies with the same flags, and
will help support default flags for a range of future requests.
Commit by Josh Triplett and Jamey Sharp.
AC_CHECK_FUNC(poll, [AC_DEFINE(USE_POLL, 1, [poll() function is available])], )
;;
esac
unset _ac_xorg_macosx_version_min
;;
*)
AC_CHECK_FUNC(poll, [AC_DEFINE(USE_POLL, 1, [poll() function is available])], )
;;
esac
XCB_EXTENSION(Composite, "yes")
XCB_EXTENSION(Damage, "yes")
XCB_EXTENSION(DPMS, "yes")
XCB_EXTENSION(GLX, "yes")
XCB_EXTENSION(RandR, "yes")
XCB_EXTENSION(Record, "yes")
XCB_EXTENSION(Render, "yes")
XCB_EXTENSION(Resource, "yes")
XCB_EXTENSION(Screensaver, "yes")
XCB_EXTENSION(Shape, "yes")
XCB_EXTENSION(Shm, "yes")
XCB_EXTENSION(Sync, "yes")
XCB_EXTENSION(Xevie, "yes")
XCB_EXTENSION(XFixes, "yes")
XCB_EXTENSION(XFree86-DRI, "yes")
XCB_EXTENSION(Xinerama, "yes")
XCB_EXTENSION(XInput, "no")
XCB_EXTENSION(Xprint, "yes")
XCB_EXTENSION(SELinux, "no")
XCB_EXTENSION(XTest, "yes")
XCB_EXTENSION(Xv, "yes")
XCB_EXTENSION(XvMC, "yes")
dnl Link with winsock for socket functions on MinGW
case $host_os in
*mingw*)
AC_CHECK_LIB([ws2_32],[main])
;;
*)
;;
esac
XCB_EXTENSION(Composite, yes)
XCB_EXTENSION(Damage, yes)
XCB_EXTENSION(Dbe, yes)
XCB_EXTENSION(DPMS, yes)
XCB_EXTENSION(DRI2, yes)
XCB_EXTENSION(DRI3, $have_sendmsg)
XCB_EXTENSION(GE, no)
XCB_EXTENSION(GLX, yes)
XCB_EXTENSION(Present, yes)
XCB_EXTENSION(RandR, yes)
XCB_EXTENSION(Record, yes)
XCB_EXTENSION(Render, yes)
XCB_EXTENSION(Resource, yes)
XCB_EXTENSION(Screensaver, yes)
XCB_EXTENSION(Shape, yes)
XCB_EXTENSION(Shm, yes)
XCB_EXTENSION(Sync, yes)
XCB_EXTENSION(Xevie, no)
XCB_EXTENSION(XFixes, yes)
XCB_EXTENSION(XFree86-DRI, yes)
XCB_EXTENSION(Xinerama, yes)
XCB_EXTENSION(XInput, yes)
XCB_EXTENSION(XKB, yes)
XCB_EXTENSION(Xprint, no)
XCB_EXTENSION(SELinux, no)
XCB_EXTENSION(XTest, yes)
XCB_EXTENSION(Xv, yes)
XCB_EXTENSION(XvMC, yes)
AC_ARG_WITH(serverside-support, AS_HELP_STRING([--with-serverside-support], [Build with support for server-side usage of xcb. This is still EXPERIMENTAL! ABI/API may change! (default: no)]), [XCB_SERVERSIDE_SUPPORT=$withval], [XCB_SERVERSIDE_SUPPORT=no])
AM_CONDITIONAL(XCB_SERVERSIDE_SUPPORT, test "x$XCB_SERVERSIDE_SUPPORT" = "xyes")