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>
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>
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>
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>
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>
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>
_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>
With this patch, `ico -threads 2` runs without deadlock.
Many thanks to Christoph Pfister <christophpfister@gmail.com> for
pointing out the problem, providing detailed analyses, explaining it to
me repeatedly until I understood what was going on, and proposing and
reviewing possible solutions.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Acked-by: Christoph Pfister <christophpfister@gmail.com>
But do still print a full backtrace, on platforms where that's
supported.
This commit follows the spirit of Novell's libxcb-sloppy-lock.diff.
I strongly opposed proposals like this one for a long time. Originally I
had a very good reason: libX11, when compiled to use XCB, would crash
soon after a locking correctness violation, so it was better to have an
informative assert failure than a mystifying crash soon after.
It took some time for me to realize that I'd changed the libX11
implementation (for unrelated reasons) so that it could survive most
invalid locking situations, as long as it wasn't actually being used
from multiple threads concurrently.
The other thing that has changed is that most of the code with incorrect
locking has now been fixed. The value of the assert is accordingly
lower.
However, remaining broken callers do need to be fixed. That's why libXCB
will still noisily print a stacktrace (if possible) on each assertion
failure, even when assert isn't actually invoked to abort() the program;
and that's why aborting is still default. This environment variable is
provided only for use as a temporary workaround for broken applications.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Acked-by: Josh Triplett <josh@freedesktop.org>
Rename API to follow a new naming convention:
* XCB_CONSTANTS_UPPERCASE_WITH_UNDERSCORES
* xcb_functions_lowercase_with_underscores
* xcb_types_lowercase_with_underscores_and_suffix_t
* expand all abbreviations like "req", "rep", and "iter"
Word boundaries for the names in the protocol descriptions fall:
* Wherever the protocol descriptions already have an underscore
* Between a lowercase letter and a subsequent uppercase letter
* Before the last uppercase letter in a string of uppercase letters followed
by a lowercase letter (such as in LSBFirst between LSB and First)
* Before and after a string of digits (with exceptions for sized types like
xcb_char2b_t and xcb_glx_float32_t to match the stdint.h convention)
Also fix up some particular naming issues:
* Rename shape_op and shape_kind to drop the "shape_" prefix, since otherwise
these types end up as xcb_shape_shape_{op,kind}_t.
* Remove leading underscores from enums in the GLX protocol description,
previously needed to ensure a word separator, but now redundant.
This renaming breaks code written for the previous API naming convention. The
scripts in XCB's tools directory will convert code written for the old API to
use the new API; they work well enough that we used them to convert the
non-program-generated code in XCB, and when run on the old program-generated
code, they almost exactly reproduce the new program-generated code (modulo
whitespace and bugs in the old code generator).
Authors: Vincent Torri, Thomas Hunger, Josh Triplett
This requires dynamically allocating memory in XCBSendRequest, but this
malloc/free pair turns out to cause a 30% speed hit for the 'x11perf -noop'
test -- so for the moment I use alloca where available and fall back to malloc
on other platforms. Later I think I'll change the contract of XCBSendRequest
so the caller is responsible for memory allocation, because the caller ought
to always be able to stack-allocate here.