summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-01-12Bump xcb-proto requirementJulien Danjou1-1/+1
We are now unable to build xcb-proto before 1.7. Signed-off-by: Julien Danjou <julien@danjou.info>
2012-01-11Release libxcb 1.8Julien Danjou2-1/+46
Signed-off-by: Julien Danjou <julien@danjou.info>
2012-01-11Use WSAStartup()/WSACleanup() on WIN32Ryan Pavlik2-1/+16
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>
2012-01-11Fix include order with Xdmcp on WIN32Ryan Pavlik1-3/+4
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>
2012-01-11Fix WIN32 compilation after commit 163c47bdc0d32785d831e4c93fea9ab7e023446bJon TURNEY2-2/+2
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>
2012-01-11Added more error states and removed global error_connectionArvind Umrao6-26/+72
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>
2012-01-11Make xcb_take_socket keep flushing until idleKeith Packard1-1/+7
_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>
2011-09-02Fix a dead-lock due to xcb_poll_for_replyUli Schlachter1-1/+1
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>
2011-08-24Keep ALIGNOF definition out of the public namespace.Jamey Sharp1-3/+3
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>
2011-08-24Support pre-IPv6 systems (without getaddrinfo)Markus Duft3-7/+54
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>
2011-08-24Compute alignment correctlyUli Schlachter1-1/+11
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>
2011-08-18Drop AI_ADDRCONFIG when resolving TCP addressesMichael Stapelberg1-3/+0
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.
2011-05-11Insert, not append explicit xcbgen dir python pathJames Jones1-1/+1
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>
2011-05-04Add support for building with Python 3David Coles2-20/+21
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>
2011-04-12Revert "Introduce xcb_wait_for_event_until, for consuming responses in ↵Jamey Sharp3-79/+3
wire-order." 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 2415c11dec5e5adb0c17f98aa52fbb371a4f8f23. Conflicts: src/xcb.h src/xcb_in.c Signed-off-by: Jamey Sharp <jamey@minilop.net>
2011-04-12Introduce a variant of xcb_poll_for_event for examining event queue.Rami Ylimäki2-2/+28
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>
2011-04-12If protocol is "unix", use a Unix domain socket, not TCPAlan Coopersmith1-8/+6
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>
2011-04-12Make launchd code in xcb_util.c match surrounding code indent levelsAlan Coopersmith1-5/+5
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2011-04-12Handle XGE events with the "send event" flagCarlos Garnacho1-1/+1
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>
2011-04-04Add #include <sys/socket.h> to xcb_conn.cAlan Coopersmith1-0/+1
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>
2011-04-04Remove unused DECnet codeAlan Coopersmith1-65/+6
"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>
2011-04-04Use special path to sockets when running under Solaris Trusted ExtensionsAlan Coopersmith2-0/+25
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>
2011-03-24Prevent theoretical double free and leak on get_peer_sock_name.Rami Ylimäki1-4/+7
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>
2011-03-19Delete the old c-client.xsl.Jamey Sharp1-1551/+0
It hasn't been used since libxcb 1.1.90.1, released in 2008. Signed-off-by: Jamey Sharp <jamey@minilop.net>
2011-03-18Introduce xcb_wait_for_event_until, for consuming responses in wire-order.Jamey Sharp3-3/+79
Signed-off-by: Jamey Sharp <jamey@minilop.net> Reviewed-by: Josh Triplett <josh@freedesktop.org>
2011-03-18Dequeue readers that can't receive any new responses.Jamey Sharp1-12/+15
Signed-off-by: Jamey Sharp <jamey@minilop.net> Reviewed-by: Josh Triplett <josh@freedesktop.org>
2011-03-18Factor reader_list management out of wait_for_reply.Jamey Sharp1-23/+22
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>
2011-03-18Enable AM_SILENT_RULES on automake 1.11 or newer.Jamey Sharp1-0/+1
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>
2011-03-14Prevent reply waiters from being blocked.Rami Ylimäki1-1/+1
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>
2011-03-13Include XKB in ./configure's summary output.Jamey Sharp1-0/+1
Signed-off-by: Jamey Sharp <jamey@minilop.net>
2011-03-13Merge branch 'master' of git+ssh://git.freedesktop.org/git/xcb/libxcbJamey Sharp12-143/+1580
Apparently I forgot to push these months ago.
2011-03-04darwin: Don't use poll() when expected to run on darwin10 and priorJeremy Huddleston1-2/+17
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
2011-01-27Don't try to sizeof(void)Peter Harris1-4/+9
sizeof(void) is a gcc extension, and not portable. Xorg Bugzilla 31959 http://bugs.freedesktop.org/show_bug.cgi?id=31959 http://lists.freedesktop.org/archives/xcb/2010-May/006039.html Signed-off-by: Peter Harris <pharris@opentext.com> Tested-by: Cyril Brulebois <kibi@debian.org>
2011-01-20fix Windows build and installationVincent Torri2-24/+37
2010-12-23Merge branch 'master' of git://anongit.freedesktop.org/~peterh/libxcbPeter Harris10-110/+1500
2010-12-12Don't validate FD_SETSIZE on Win32Jeetu Golani1-0/+2
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>
2010-11-27xcb_take_socket: Document sequence wrap requirementsUli Schlachter1-4/+11
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>
2010-11-23xcb_auth: Fix memory leak in _xcb_get_auth_info.Nick Bowler1-3/+8
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>
2010-10-09xcb_in: Use 64-bit sequence numbers internally everywhere.Jamey Sharp2-31/+32
Widen sequence numbers on entry to those public APIs that still take 32-bit sequence numbers. Signed-off-by: Jamey Sharp <jamey@minilop.net>
2010-10-09xcb_discard_reply: Simplify by re-using poll_for_reply helper.Jamey Sharp1-45/+7
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>
2010-10-09xcb_request_check: Hold the I/O lock while deciding to sync.Jamey Sharp3-19/+33
Signed-off-by: Jamey Sharp <jamey@minilop.net>
2010-10-09xcb_send_request: Send all requests using a common internal send_request.Jamey Sharp1-49/+50
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>
2010-09-22Fix _unserialize of reply headersPeter Harris1-2/+3
This cleans up a number of warnings, and passes the sequence number through correctly. Signed-off-by: Peter Harris <pharris@opentext.com>
2010-09-22Clean up a couple of warnings in xprintPeter Harris1-1/+1
Signed-off-by: Peter Harris <pharris@opentext.com>
2010-09-22Make *_unserialize safe to use on buffers in-placePeter Harris1-4/+5
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>
2010-09-22Fix memory leak in _sizeof implemented with _unserializePeter Harris1-2/+7
Signed-off-by: Peter Harris <pharris@opentext.com>
2010-09-22Don't emit out-of-module sizeof definitionsPeter Harris1-2/+3
Signed-off-by: Peter Harris <pharris@opentext.com>
2010-09-19Allow disconnecting connections that are in error state.Josh Triplett3-4/+4
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>
2010-09-10Add xkb.* to gitignorePeter Harris1-0/+1
Signed-off-by: Peter Harris <pharris@opentext.com>
2010-09-08Merge branch 'gsoc2010' of git://anongit.freedesktop.org/~chr/libxcbPeter Harris9-110/+1491
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-21 18:08:01 +0000