summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJonas Ådahl <jadahl@gmail.com>2015-10-02 11:18:12 +0800
committerJonas Ådahl <jadahl@gmail.com>2016-01-16 16:37:36 +0800
commit0b44298a15674121ff54585c706bfdefc0d9942a (patch)
treefcdacfc42ccbc2b3705da6f3359b48e534505a83
parent0edeeb9cd5806959660af54d63fe9d402d50e6e7 (diff)
downloadwayland-0b44298a15674121ff54585c706bfdefc0d9942a.tar.gz
client: Remove misplaced documentation about main loop intergration
There was documentation about how to integrate the display server file descriptor in the documentation about wl_display_dispatch_pending(). This is not the right place to put it, and it also had incorrect usage of the API (calling wl_display_dispatch_queue() on input on an unrelated fd) as an example. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Daniel Stone <daniels@collabora.com>
-rw-r--r--src/wayland-client.c22
1 files changed, 0 insertions, 22 deletions
diff --git a/src/wayland-client.c b/src/wayland-client.c
index cd94fd8..33eb247 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -1617,28 +1617,6 @@ wl_display_dispatch(struct wl_display *display)
* attempt to read the display fd and simply returns zero if the main
* queue is empty, i.e., it doesn't block.
*
- * This is necessary when a client's main loop wakes up on some fd other
- * than the display fd (network socket, timer fd, etc) and calls \ref
- * wl_display_dispatch_queue() from that callback. This may queue up
- * events in other queues while reading all data from the display fd.
- * When the main loop returns from the handler, the display fd
- * no longer has data, causing a call to \em poll(2) (or similar
- * functions) to block indefinitely, even though there are events ready
- * to dispatch.
- *
- * To proper integrate the wayland display fd into a main loop, the
- * client should always call wl_display_dispatch_pending() and then
- * \ref wl_display_flush() prior to going back to sleep. At that point,
- * the fd typically doesn't have data so attempting I/O could block, but
- * events queued up on the default queue should be dispatched.
- *
- * A real-world example is a main loop that wakes up on a timerfd (or a
- * sound card fd becoming writable, for example in a video player), which
- * then triggers GL rendering and eventually eglSwapBuffers().
- * eglSwapBuffers() may call wl_display_dispatch_queue() if it didn't
- * receive the frame event for the previous frame, and as such queue
- * events in the default queue.
- *
* \sa wl_display_dispatch(), wl_display_dispatch_queue(),
* wl_display_flush()
*