diff options
author | Jonas Ådahl <jadahl@gmail.com> | 2015-10-02 11:18:12 +0800 |
---|---|---|
committer | Jonas Ådahl <jadahl@gmail.com> | 2016-01-16 16:37:36 +0800 |
commit | 0b44298a15674121ff54585c706bfdefc0d9942a (patch) | |
tree | fcdacfc42ccbc2b3705da6f3359b48e534505a83 | |
parent | 0edeeb9cd5806959660af54d63fe9d402d50e6e7 (diff) | |
download | wayland-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.c | 22 |
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() * |