Import libX11 1.1.1 from X.Org 7.2RC3

1 files changed, 54 insertions, 0 deletions

diff --git a/lib/libX11/NEWS b/lib/libX11/NEWS
index fb1cc140f..9ac5fc22b 100644
--- a/lib/libX11/NEWS
+++ b/lib/libX11/NEWS
@@ -1,3 +1,57 @@
+Version 1.1.1 - 2006-11-30
+
+The "xcompmgr is hard, let's go releasing" release
+
+* Fix Bug #9154 and friends, to unbreak xcompmgr:
+  Always process an event for _XReadEvents, even if an error occurs.
+  Previously, process_responses (in the wait_for_first_event case called
+  from _XReadEvents) considered any return from xcb_wait_for_event
+  sufficient to think it had processed an event. If xcb_wait_for_event
+  returned an error, and no more events occurred before process_responses
+  called xcb_poll_for_event, process_responses would try to return with
+  dpy->head NULL, and would fail an assertion for the _XReadEvents
+  postcondition. Now, process_responses continues using xcb_wait_for_event
+  until it gets an event.
+
+* Bug #9153: Fix access to freed memory.
+  The fix for bug #8622 introduced a smaller bug where _XReply would
+  read memory shortly after freeing it. This patch caches the needed
+  value in a stack-allocated variable before the heap-allocated memory
+  is freed.
+
+* libx11 doesn't use inputproto in public headers; don't require it in x11.pc.
+  Based on a Debian patch.
+
+* Debian bug #354315: Clarify return value in XGetWindowAttributes man page.
+  Patch by Debian user Ross Combs.
+
+
+Version 1.1 - 2006-11-23
+
+* Add note in man-page that XListFontsWithInfo is not thread-safe.  _XReply
+  drops the Display lock, so the value of dpy->request may change before
+  _XReply is called again.  Jamey Sharp discovered this by inspection a few
+  years ago.
+
+* Fix Bug #8622, by fixing the response processing order for threaded apps.
+  process_responses (the common code for _XReply, _XReadEvents, and
+  _XEventsQueued) now handles responses in order, by adding condition variables
+  to the list of outstanding requests in dpy->xcb->pending_requests, and
+  blocking on them when those requests should get processed, to allow _XReply
+  to process them; if actually called from _XReply, it returns when _XReply's
+  request should get processed.  _XReply broadcasts on its condition variable
+  after it has read its reply and re-acquired the display lock.
+
+* Don't hold the display lock around callbacks to the application. This avoids
+  recursive locking of the display lock (which triggers an XCB locking
+  assertion), particularly with emacs.
+
+* Add xcb-xlib dependency to x11.pc when built against XCB.
+
+* Allocate the right amount of memory for dpy->lock_fns.  Fixes a crash on
+  startup with gdk.
+
+
 Version 1.1 RC2 - 2006-11-02
 
 Benno Schulenberg: