2008-12-02 15:15:01 -05:00
|
|
|
/*
|
2012-10-04 16:54:22 -04:00
|
|
|
* Copyright © 2008-2012 Kristian Høgsberg
|
|
|
|
|
* Copyright © 2010-2012 Intel Corporation
|
2008-12-02 15:15:01 -05:00
|
|
|
*
|
|
|
|
|
* Permission to use, copy, modify, distribute, and sell this software and its
|
|
|
|
|
* documentation for any purpose is hereby granted without fee, provided that
|
|
|
|
|
* the above copyright notice appear in all copies and that both that copyright
|
|
|
|
|
* notice and this permission notice appear in supporting documentation, and
|
|
|
|
|
* that the name of the copyright holders not be used in advertising or
|
|
|
|
|
* publicity pertaining to distribution of the software without specific,
|
|
|
|
|
* written prior permission. The copyright holders make no representations
|
|
|
|
|
* about the suitability of this software for any purpose. It is provided "as
|
|
|
|
|
* is" without express or implied warranty.
|
|
|
|
|
*
|
|
|
|
|
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
|
|
|
|
|
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
|
|
|
|
|
* EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
|
|
|
|
|
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
|
|
|
|
|
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
|
|
|
|
|
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
|
|
|
|
|
* OF THIS SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
2008-10-07 10:10:36 -04:00
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <stdint.h>
|
|
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <stdio.h>
|
2011-07-14 18:56:40 +03:00
|
|
|
#include <stdbool.h>
|
2008-10-07 10:10:36 -04:00
|
|
|
#include <errno.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
#include <unistd.h>
|
|
|
|
|
#include <sys/socket.h>
|
|
|
|
|
#include <sys/un.h>
|
|
|
|
|
#include <ctype.h>
|
2008-12-21 21:50:23 -05:00
|
|
|
#include <assert.h>
|
2011-04-11 09:24:11 -04:00
|
|
|
#include <fcntl.h>
|
2008-10-07 10:10:36 -04:00
|
|
|
#include <sys/poll.h>
|
2012-10-04 17:42:49 -04:00
|
|
|
#include <pthread.h>
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2008-11-23 23:41:08 -05:00
|
|
|
#include "wayland-util.h"
|
2012-03-21 11:11:26 +02:00
|
|
|
#include "wayland-os.h"
|
2008-10-08 13:32:07 -04:00
|
|
|
#include "wayland-client.h"
|
2011-11-18 13:46:56 -05:00
|
|
|
#include "wayland-private.h"
|
2008-10-08 13:32:07 -04:00
|
|
|
|
2008-12-30 11:03:33 -05:00
|
|
|
struct wl_proxy {
|
2010-12-01 17:07:41 -05:00
|
|
|
struct wl_object object;
|
2008-12-30 11:03:33 -05:00
|
|
|
struct wl_display *display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
struct wl_event_queue *queue;
|
|
|
|
|
int id_deleted;
|
2009-09-18 09:49:21 -04:00
|
|
|
void *user_data;
|
2008-10-07 10:10:36 -04:00
|
|
|
};
|
|
|
|
|
|
2011-04-14 10:38:44 -04:00
|
|
|
struct wl_global {
|
|
|
|
|
uint32_t id;
|
|
|
|
|
char *interface;
|
|
|
|
|
uint32_t version;
|
|
|
|
|
struct wl_list link;
|
|
|
|
|
};
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
struct wl_event_queue {
|
|
|
|
|
struct wl_list event_list;
|
|
|
|
|
pthread_cond_t cond;
|
|
|
|
|
};
|
|
|
|
|
|
2008-12-30 11:03:33 -05:00
|
|
|
struct wl_display {
|
|
|
|
|
struct wl_proxy proxy;
|
|
|
|
|
struct wl_connection *connection;
|
|
|
|
|
int fd;
|
2012-08-14 13:16:10 -04:00
|
|
|
int close_fd;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
pthread_t display_thread;
|
2011-08-19 22:50:53 -04:00
|
|
|
struct wl_map objects;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
struct wl_event_queue queue;
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_t mutex;
|
2008-12-30 11:03:33 -05:00
|
|
|
};
|
|
|
|
|
|
2011-02-10 12:27:35 -05:00
|
|
|
static int wl_debug = 0;
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
static void
|
|
|
|
|
wl_event_queue_init(struct wl_event_queue *queue)
|
|
|
|
|
{
|
|
|
|
|
wl_list_init(&queue->event_list);
|
|
|
|
|
pthread_cond_init(&queue->cond, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wl_event_queue_release(struct wl_event_queue *queue)
|
|
|
|
|
{
|
|
|
|
|
struct wl_closure *closure;
|
|
|
|
|
|
|
|
|
|
while (!wl_list_empty(&queue->event_list)) {
|
|
|
|
|
closure = container_of(queue->event_list.next,
|
|
|
|
|
struct wl_closure, link);
|
|
|
|
|
wl_list_remove(&closure->link);
|
|
|
|
|
wl_closure_destroy(closure);
|
|
|
|
|
}
|
|
|
|
|
pthread_cond_destroy(&queue->cond);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WL_EXPORT void
|
|
|
|
|
wl_event_queue_destroy(struct wl_event_queue *queue)
|
|
|
|
|
{
|
|
|
|
|
wl_event_queue_release(queue);
|
|
|
|
|
free(queue);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WL_EXPORT struct wl_event_queue *
|
|
|
|
|
wl_display_create_queue(struct wl_display *display)
|
|
|
|
|
{
|
|
|
|
|
struct wl_event_queue *queue;
|
|
|
|
|
|
|
|
|
|
queue = malloc(sizeof *queue);
|
|
|
|
|
if (queue == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
wl_event_queue_init(queue);
|
|
|
|
|
|
|
|
|
|
return queue;
|
|
|
|
|
}
|
|
|
|
|
|
2010-08-10 14:02:48 -04:00
|
|
|
WL_EXPORT struct wl_proxy *
|
2011-08-19 13:44:01 -04:00
|
|
|
wl_proxy_create(struct wl_proxy *factory, const struct wl_interface *interface)
|
2008-12-30 11:03:33 -05:00
|
|
|
{
|
|
|
|
|
struct wl_proxy *proxy;
|
2011-08-19 13:44:01 -04:00
|
|
|
struct wl_display *display = factory->display;
|
2008-12-30 11:03:33 -05:00
|
|
|
|
|
|
|
|
proxy = malloc(sizeof *proxy);
|
|
|
|
|
if (proxy == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2010-12-01 17:07:41 -05:00
|
|
|
proxy->object.interface = interface;
|
2011-02-18 15:28:54 -05:00
|
|
|
proxy->object.implementation = NULL;
|
2012-10-04 17:42:49 -04:00
|
|
|
proxy->display = display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
proxy->queue = factory->queue;
|
|
|
|
|
proxy->id_deleted = 0;
|
2012-10-04 17:42:49 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
2011-11-18 21:59:36 -05:00
|
|
|
proxy->object.id = wl_map_insert_new(&display->objects,
|
|
|
|
|
WL_MAP_CLIENT_SIDE, proxy);
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_unlock(&display->mutex);
|
2011-11-18 21:59:36 -05:00
|
|
|
|
|
|
|
|
return proxy;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-11 14:55:59 +03:00
|
|
|
/* The caller should hold the display lock */
|
|
|
|
|
static struct wl_proxy *
|
2011-11-18 21:59:36 -05:00
|
|
|
wl_proxy_create_for_id(struct wl_proxy *factory,
|
|
|
|
|
uint32_t id, const struct wl_interface *interface)
|
|
|
|
|
{
|
|
|
|
|
struct wl_proxy *proxy;
|
|
|
|
|
struct wl_display *display = factory->display;
|
|
|
|
|
|
|
|
|
|
proxy = malloc(sizeof *proxy);
|
|
|
|
|
if (proxy == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
proxy->object.interface = interface;
|
|
|
|
|
proxy->object.implementation = NULL;
|
2011-11-15 08:58:34 -05:00
|
|
|
proxy->object.id = id;
|
2008-12-30 11:03:33 -05:00
|
|
|
proxy->display = display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
proxy->queue = factory->queue;
|
|
|
|
|
proxy->id_deleted = 0;
|
2012-10-04 17:42:49 -04:00
|
|
|
|
2011-11-15 08:58:34 -05:00
|
|
|
wl_map_insert_at(&display->objects, id, proxy);
|
2008-12-30 11:03:33 -05:00
|
|
|
|
|
|
|
|
return proxy;
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-02 20:22:42 -04:00
|
|
|
WL_EXPORT void
|
|
|
|
|
wl_proxy_destroy(struct wl_proxy *proxy)
|
|
|
|
|
{
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_lock(&proxy->display->mutex);
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
if (proxy->id_deleted)
|
|
|
|
|
wl_map_remove(&proxy->display->objects, proxy->object.id);
|
|
|
|
|
else if (proxy->object.id < WL_SERVER_ID_START)
|
2011-11-18 21:59:36 -05:00
|
|
|
wl_map_insert_at(&proxy->display->objects,
|
|
|
|
|
proxy->object.id, WL_ZOMBIE_OBJECT);
|
|
|
|
|
else
|
|
|
|
|
wl_map_insert_at(&proxy->display->objects,
|
|
|
|
|
proxy->object.id, NULL);
|
2012-10-04 17:42:49 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&proxy->display->mutex);
|
|
|
|
|
|
2010-09-02 20:22:42 -04:00
|
|
|
free(proxy);
|
|
|
|
|
}
|
|
|
|
|
|
2010-08-10 10:53:44 -04:00
|
|
|
WL_EXPORT int
|
2010-08-10 14:02:48 -04:00
|
|
|
wl_proxy_add_listener(struct wl_proxy *proxy,
|
|
|
|
|
void (**implementation)(void), void *data)
|
2008-12-21 23:37:12 -05:00
|
|
|
{
|
2011-02-18 15:28:54 -05:00
|
|
|
if (proxy->object.implementation) {
|
|
|
|
|
fprintf(stderr, "proxy already has listener\n");
|
2008-12-30 11:03:33 -05:00
|
|
|
return -1;
|
2011-02-18 15:28:54 -05:00
|
|
|
}
|
2008-12-30 11:03:33 -05:00
|
|
|
|
2011-02-18 15:28:54 -05:00
|
|
|
proxy->object.implementation = implementation;
|
|
|
|
|
proxy->user_data = data;
|
2008-12-30 11:03:33 -05:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2010-08-09 21:25:50 -04:00
|
|
|
WL_EXPORT void
|
2008-12-30 11:03:33 -05:00
|
|
|
wl_proxy_marshal(struct wl_proxy *proxy, uint32_t opcode, ...)
|
|
|
|
|
{
|
2012-06-12 17:45:25 -04:00
|
|
|
struct wl_closure *closure;
|
2008-12-30 11:03:33 -05:00
|
|
|
va_list ap;
|
|
|
|
|
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_lock(&proxy->display->mutex);
|
|
|
|
|
|
2008-12-30 11:03:33 -05:00
|
|
|
va_start(ap, opcode);
|
2012-06-12 17:45:25 -04:00
|
|
|
closure = wl_closure_vmarshal(&proxy->object, opcode, ap,
|
|
|
|
|
&proxy->object.interface->methods[opcode]);
|
2008-12-30 11:03:33 -05:00
|
|
|
va_end(ap);
|
2010-09-07 21:34:45 -04:00
|
|
|
|
2012-06-12 17:45:25 -04:00
|
|
|
if (closure == NULL) {
|
2011-12-16 10:29:36 +02:00
|
|
|
fprintf(stderr, "Error marshalling request\n");
|
|
|
|
|
abort();
|
|
|
|
|
}
|
|
|
|
|
|
2012-07-23 19:54:42 +01:00
|
|
|
if (wl_debug)
|
|
|
|
|
wl_closure_print(closure, &proxy->object, true);
|
|
|
|
|
|
2012-06-12 17:45:25 -04:00
|
|
|
if (wl_closure_send(closure, proxy->display->connection)) {
|
2012-02-29 11:07:48 -05:00
|
|
|
fprintf(stderr, "Error sending request: %m\n");
|
|
|
|
|
abort();
|
|
|
|
|
}
|
2011-02-10 12:27:35 -05:00
|
|
|
|
2012-06-12 17:45:25 -04:00
|
|
|
wl_closure_destroy(closure);
|
2012-10-04 17:42:49 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&proxy->display->mutex);
|
2008-12-30 11:03:33 -05:00
|
|
|
}
|
|
|
|
|
|
2008-12-24 19:30:25 -05:00
|
|
|
static void
|
2011-05-11 10:57:06 -04:00
|
|
|
display_handle_error(void *data,
|
|
|
|
|
struct wl_display *display, struct wl_object *object,
|
|
|
|
|
uint32_t code, const char *message)
|
2008-12-24 19:30:25 -05:00
|
|
|
{
|
2012-07-23 19:54:42 +01:00
|
|
|
fprintf(stderr, "%s@%u: error %d: %s\n",
|
2011-05-11 10:57:06 -04:00
|
|
|
object->interface->name, object->id, code, message);
|
2010-08-05 17:44:31 -04:00
|
|
|
abort();
|
2008-12-24 19:30:25 -05:00
|
|
|
}
|
|
|
|
|
|
2011-11-15 22:20:28 -05:00
|
|
|
static void
|
|
|
|
|
display_handle_delete_id(void *data, struct wl_display *display, uint32_t id)
|
|
|
|
|
{
|
|
|
|
|
struct wl_proxy *proxy;
|
|
|
|
|
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
|
2011-11-15 22:20:28 -05:00
|
|
|
proxy = wl_map_lookup(&display->objects, id);
|
|
|
|
|
if (proxy != WL_ZOMBIE_OBJECT)
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
proxy->id_deleted = 1;
|
2011-11-15 22:20:28 -05:00
|
|
|
else
|
|
|
|
|
wl_map_remove(&display->objects, id);
|
2012-10-04 17:42:49 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
2011-11-15 22:20:28 -05:00
|
|
|
}
|
|
|
|
|
|
2008-12-24 19:30:25 -05:00
|
|
|
static const struct wl_display_listener display_listener = {
|
2011-05-11 10:57:06 -04:00
|
|
|
display_handle_error,
|
2011-11-15 22:20:28 -05:00
|
|
|
display_handle_delete_id
|
2008-12-24 19:30:25 -05:00
|
|
|
};
|
|
|
|
|
|
2011-04-11 09:14:43 -04:00
|
|
|
static int
|
2012-08-14 13:16:10 -04:00
|
|
|
connect_to_socket(const char *name)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2008-12-07 15:22:22 -05:00
|
|
|
struct sockaddr_un addr;
|
2008-10-07 10:10:36 -04:00
|
|
|
socklen_t size;
|
2010-12-01 15:36:20 -05:00
|
|
|
const char *runtime_dir;
|
2012-08-14 13:16:10 -04:00
|
|
|
int name_size, fd;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2010-12-01 15:36:20 -05:00
|
|
|
runtime_dir = getenv("XDG_RUNTIME_DIR");
|
2012-06-06 14:30:18 +03:00
|
|
|
if (!runtime_dir) {
|
2010-12-01 15:36:20 -05:00
|
|
|
fprintf(stderr,
|
2012-06-06 14:30:18 +03:00
|
|
|
"error: XDG_RUNTIME_DIR not set in the environment.\n");
|
|
|
|
|
|
|
|
|
|
/* to prevent programs reporting
|
|
|
|
|
* "failed to create display: Success" */
|
|
|
|
|
errno = ENOENT;
|
|
|
|
|
return -1;
|
2010-12-01 15:36:20 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (name == NULL)
|
|
|
|
|
name = getenv("WAYLAND_DISPLAY");
|
|
|
|
|
if (name == NULL)
|
|
|
|
|
name = "wayland-0";
|
|
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
|
|
|
|
|
if (fd < 0)
|
2012-06-06 14:30:18 +03:00
|
|
|
return -1;
|
|
|
|
|
|
2010-12-01 15:36:20 -05:00
|
|
|
memset(&addr, 0, sizeof addr);
|
2008-12-07 15:22:22 -05:00
|
|
|
addr.sun_family = AF_LOCAL;
|
2010-12-01 15:36:20 -05:00
|
|
|
name_size =
|
|
|
|
|
snprintf(addr.sun_path, sizeof addr.sun_path,
|
|
|
|
|
"%s/%s", runtime_dir, name) + 1;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-06-15 21:39:50 +00:00
|
|
|
assert(name_size > 0);
|
|
|
|
|
if (name_size > (int)sizeof addr.sun_path) {
|
|
|
|
|
fprintf(stderr,
|
|
|
|
|
"error: socket path \"%s/%s\" plus null terminator"
|
|
|
|
|
" exceeds 108 bytes\n", runtime_dir, name);
|
2012-08-14 13:16:10 -04:00
|
|
|
close(fd);
|
2012-06-15 21:39:50 +00:00
|
|
|
/* to prevent programs reporting
|
|
|
|
|
* "failed to add socket: Success" */
|
|
|
|
|
errno = ENAMETOOLONG;
|
|
|
|
|
return -1;
|
|
|
|
|
};
|
|
|
|
|
|
2008-12-07 15:22:22 -05:00
|
|
|
size = offsetof (struct sockaddr_un, sun_path) + name_size;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
if (connect(fd, (struct sockaddr *) &addr, size) < 0) {
|
|
|
|
|
close(fd);
|
2011-04-11 09:14:43 -04:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
return fd;
|
2011-04-11 09:14:43 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WL_EXPORT struct wl_display *
|
2012-08-14 13:16:10 -04:00
|
|
|
wl_display_connect_to_fd(int fd)
|
2011-04-11 09:14:43 -04:00
|
|
|
{
|
|
|
|
|
struct wl_display *display;
|
|
|
|
|
const char *debug;
|
|
|
|
|
|
|
|
|
|
debug = getenv("WAYLAND_DEBUG");
|
|
|
|
|
if (debug)
|
|
|
|
|
wl_debug = 1;
|
|
|
|
|
|
|
|
|
|
display = malloc(sizeof *display);
|
|
|
|
|
if (display == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
memset(display, 0, sizeof *display);
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
display->fd = fd;
|
2011-08-19 22:50:53 -04:00
|
|
|
wl_map_init(&display->objects);
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
wl_event_queue_init(&display->queue);
|
2012-10-11 17:11:54 -04:00
|
|
|
pthread_mutex_init(&display->mutex, NULL);
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2011-11-18 21:59:36 -05:00
|
|
|
wl_map_insert_new(&display->objects, WL_MAP_CLIENT_SIDE, NULL);
|
2011-08-19 22:50:53 -04:00
|
|
|
|
2010-12-01 17:07:41 -05:00
|
|
|
display->proxy.object.interface = &wl_display_interface;
|
2011-11-18 21:59:36 -05:00
|
|
|
display->proxy.object.id =
|
|
|
|
|
wl_map_insert_new(&display->objects,
|
|
|
|
|
WL_MAP_CLIENT_SIDE, display);
|
2008-12-21 21:50:23 -05:00
|
|
|
display->proxy.display = display;
|
2011-08-19 22:50:53 -04:00
|
|
|
display->proxy.object.implementation = (void(**)(void)) &display_listener;
|
2011-02-18 15:28:54 -05:00
|
|
|
display->proxy.user_data = display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
display->proxy.queue = &display->queue;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-10-04 16:54:22 -04:00
|
|
|
display->connection = wl_connection_create(display->fd);
|
2011-03-11 14:43:10 +02:00
|
|
|
if (display->connection == NULL) {
|
2011-08-19 22:50:53 -04:00
|
|
|
wl_map_release(&display->objects);
|
2011-03-11 14:43:10 +02:00
|
|
|
close(display->fd);
|
|
|
|
|
free(display);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2011-04-14 10:38:44 -04:00
|
|
|
|
2008-10-08 13:32:07 -04:00
|
|
|
return display;
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
WL_EXPORT struct wl_display *
|
|
|
|
|
wl_display_connect(const char *name)
|
|
|
|
|
{
|
|
|
|
|
struct wl_display *display;
|
|
|
|
|
char *connection, *end;
|
|
|
|
|
int flags, fd;
|
|
|
|
|
|
|
|
|
|
connection = getenv("WAYLAND_SOCKET");
|
|
|
|
|
if (connection) {
|
|
|
|
|
fd = strtol(connection, &end, 0);
|
|
|
|
|
if (*end != '\0')
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
flags = fcntl(fd, F_GETFD);
|
|
|
|
|
if (flags != -1)
|
|
|
|
|
fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
|
|
|
|
|
unsetenv("WAYLAND_SOCKET");
|
|
|
|
|
} else {
|
|
|
|
|
fd = connect_to_socket(name);
|
|
|
|
|
if (fd < 0)
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
display = wl_display_connect_to_fd(fd);
|
|
|
|
|
if (display)
|
|
|
|
|
display->close_fd = 1;
|
|
|
|
|
|
|
|
|
|
return display;
|
|
|
|
|
}
|
|
|
|
|
|
2008-11-08 15:39:41 -05:00
|
|
|
WL_EXPORT void
|
2012-02-27 17:10:03 +01:00
|
|
|
wl_display_disconnect(struct wl_display *display)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2008-10-08 13:32:07 -04:00
|
|
|
wl_connection_destroy(display->connection);
|
2011-08-19 22:50:53 -04:00
|
|
|
wl_map_release(&display->objects);
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
wl_event_queue_release(&display->queue);
|
2012-10-11 17:11:54 -04:00
|
|
|
pthread_mutex_destroy(&display->mutex);
|
2011-06-14 11:41:54 +02:00
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
if (display->close_fd)
|
|
|
|
|
close(display->fd);
|
|
|
|
|
|
2008-10-08 13:32:07 -04:00
|
|
|
free(display);
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
2008-11-08 15:39:41 -05:00
|
|
|
WL_EXPORT int
|
2012-10-04 16:54:22 -04:00
|
|
|
wl_display_get_fd(struct wl_display *display)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2008-10-08 13:32:07 -04:00
|
|
|
return display->fd;
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
2011-07-29 19:51:22 -07:00
|
|
|
static void
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-11 22:25:51 -04:00
|
|
|
sync_callback(void *data, struct wl_callback *callback, uint32_t serial)
|
2010-09-03 14:46:38 -04:00
|
|
|
{
|
2011-07-29 19:51:22 -07:00
|
|
|
int *done = data;
|
2010-09-03 14:46:38 -04:00
|
|
|
|
2011-07-29 19:51:22 -07:00
|
|
|
*done = 1;
|
|
|
|
|
wl_callback_destroy(callback);
|
2010-09-03 14:46:38 -04:00
|
|
|
}
|
|
|
|
|
|
2011-07-29 19:51:22 -07:00
|
|
|
static const struct wl_callback_listener sync_listener = {
|
|
|
|
|
sync_callback
|
|
|
|
|
};
|
2010-09-03 14:46:38 -04:00
|
|
|
|
2011-07-29 19:51:22 -07:00
|
|
|
WL_EXPORT void
|
|
|
|
|
wl_display_roundtrip(struct wl_display *display)
|
|
|
|
|
{
|
|
|
|
|
struct wl_callback *callback;
|
|
|
|
|
int done;
|
|
|
|
|
|
|
|
|
|
done = 0;
|
|
|
|
|
callback = wl_display_sync(display);
|
|
|
|
|
wl_callback_add_listener(callback, &sync_listener, &done);
|
|
|
|
|
while (!done)
|
2012-10-04 16:54:22 -04:00
|
|
|
wl_display_dispatch(display);
|
2010-09-03 14:46:38 -04:00
|
|
|
}
|
|
|
|
|
|
2012-06-28 22:01:58 -04:00
|
|
|
static int
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
create_proxies(struct wl_proxy *sender, struct wl_closure *closure)
|
2012-06-28 22:01:58 -04:00
|
|
|
{
|
|
|
|
|
struct wl_proxy *proxy;
|
|
|
|
|
const char *signature;
|
2012-07-23 19:54:41 +01:00
|
|
|
struct argument_details arg;
|
2012-06-28 22:01:58 -04:00
|
|
|
uint32_t id;
|
|
|
|
|
int i;
|
2012-07-23 19:54:41 +01:00
|
|
|
int count;
|
2012-06-28 22:01:58 -04:00
|
|
|
|
|
|
|
|
signature = closure->message->signature;
|
2012-07-23 19:54:41 +01:00
|
|
|
count = arg_count_for_signature(signature) + 2;
|
|
|
|
|
for (i = 2; i < count; i++) {
|
|
|
|
|
signature = get_next_argument(signature, &arg);
|
|
|
|
|
switch (arg.type) {
|
2012-06-28 22:01:58 -04:00
|
|
|
case 'n':
|
2012-07-23 19:54:41 +01:00
|
|
|
id = **(uint32_t **) closure->args[i];
|
|
|
|
|
if (id == 0) {
|
|
|
|
|
*(void **) closure->args[i] = NULL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
proxy = wl_proxy_create_for_id(sender, id,
|
2012-07-23 19:54:41 +01:00
|
|
|
closure->message->types[i - 2]);
|
2012-06-28 22:01:58 -04:00
|
|
|
if (proxy == NULL)
|
|
|
|
|
return -1;
|
2012-07-23 19:54:41 +01:00
|
|
|
*(void **) closure->args[i] = proxy;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
2012-06-28 22:01:58 -04:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-04 17:34:18 -04:00
|
|
|
static int
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
queue_event(struct wl_display *display, int len)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2012-10-04 17:34:18 -04:00
|
|
|
uint32_t p[2], id;
|
|
|
|
|
int opcode, size;
|
2008-12-30 11:03:33 -05:00
|
|
|
struct wl_proxy *proxy;
|
2012-06-12 17:45:25 -04:00
|
|
|
struct wl_closure *closure;
|
2010-09-01 17:18:33 -04:00
|
|
|
const struct wl_message *message;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-10-04 17:34:18 -04:00
|
|
|
wl_connection_copy(display->connection, p, sizeof p);
|
|
|
|
|
id = p[0];
|
|
|
|
|
opcode = p[1] & 0xffff;
|
|
|
|
|
size = p[1] >> 16;
|
|
|
|
|
if (len < size)
|
|
|
|
|
return 0;
|
2008-12-30 11:03:33 -05:00
|
|
|
|
2012-10-04 17:34:18 -04:00
|
|
|
proxy = wl_map_lookup(&display->objects, id);
|
2011-11-15 22:20:28 -05:00
|
|
|
if (proxy == WL_ZOMBIE_OBJECT) {
|
|
|
|
|
wl_connection_consume(display->connection, size);
|
2012-10-04 17:34:18 -04:00
|
|
|
return size;
|
2012-10-11 17:12:50 -04:00
|
|
|
} else if (proxy == NULL) {
|
2010-08-30 09:47:36 -04:00
|
|
|
wl_connection_consume(display->connection, size);
|
2012-10-04 17:34:18 -04:00
|
|
|
return size;
|
2010-08-30 09:47:36 -04:00
|
|
|
}
|
|
|
|
|
|
2010-12-01 17:07:41 -05:00
|
|
|
message = &proxy->object.interface->events[opcode];
|
2012-06-12 17:45:25 -04:00
|
|
|
closure = wl_connection_demarshal(display->connection, size,
|
|
|
|
|
&display->objects, message);
|
2010-08-30 09:47:36 -04:00
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
if (closure == NULL || create_proxies(proxy, closure) < 0) {
|
2011-12-16 10:29:36 +02:00
|
|
|
fprintf(stderr, "Error demarshalling event\n");
|
2011-07-18 02:00:24 -04:00
|
|
|
abort();
|
|
|
|
|
}
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
if (wl_list_empty(&proxy->queue->event_list))
|
|
|
|
|
pthread_cond_signal(&proxy->queue->cond);
|
|
|
|
|
wl_list_insert(proxy->queue->event_list.prev, &closure->link);
|
2012-10-04 17:34:18 -04:00
|
|
|
|
|
|
|
|
return size;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
dispatch_event(struct wl_display *display, struct wl_event_queue *queue)
|
2012-10-04 17:34:18 -04:00
|
|
|
{
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
struct wl_closure *closure;
|
2012-10-04 17:34:18 -04:00
|
|
|
struct wl_proxy *proxy;
|
|
|
|
|
uint32_t id;
|
2012-10-09 12:14:34 -04:00
|
|
|
int opcode, ret;
|
2012-10-04 17:34:18 -04:00
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
closure = container_of(queue->event_list.next,
|
|
|
|
|
struct wl_closure, link);
|
2012-10-04 17:34:18 -04:00
|
|
|
wl_list_remove(&closure->link);
|
|
|
|
|
id = closure->buffer[0];
|
|
|
|
|
opcode = closure->buffer[1] & 0xffff;
|
|
|
|
|
|
2012-10-09 12:14:34 -04:00
|
|
|
/* Verify that the receiving object is still valid and look up
|
|
|
|
|
* proxies for any arguments. We have to do this just before
|
|
|
|
|
* calling the handler, since preceeding events may have
|
|
|
|
|
* destroyed either the proxy or the proxy args since the
|
|
|
|
|
* event was queued. */
|
2012-10-04 17:34:18 -04:00
|
|
|
proxy = wl_map_lookup(&display->objects, id);
|
2012-10-09 12:14:34 -04:00
|
|
|
ret = wl_closure_lookup_objects(closure, &display->objects);
|
2012-10-04 17:42:49 -04:00
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
pthread_mutex_unlock(&display->mutex);
|
2012-10-04 17:34:18 -04:00
|
|
|
|
2012-10-11 17:12:50 -04:00
|
|
|
if (proxy != WL_ZOMBIE_OBJECT &&
|
|
|
|
|
proxy->object.implementation && ret == 0) {
|
2012-10-09 12:14:34 -04:00
|
|
|
if (wl_debug)
|
|
|
|
|
wl_closure_print(closure, &proxy->object, false);
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
wl_closure_invoke(closure, &proxy->object,
|
|
|
|
|
proxy->object.implementation[opcode],
|
|
|
|
|
proxy->user_data);
|
2012-10-09 12:14:34 -04:00
|
|
|
}
|
|
|
|
|
|
2012-06-12 17:45:25 -04:00
|
|
|
wl_closure_destroy(closure);
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
|
2012-10-04 16:54:22 -04:00
|
|
|
WL_EXPORT int
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
wl_display_dispatch_queue(struct wl_display *display,
|
|
|
|
|
struct wl_event_queue *queue)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2012-10-04 17:34:18 -04:00
|
|
|
int len, size;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
|
2012-10-04 16:54:22 -04:00
|
|
|
/* FIXME: Handle flush errors, EAGAIN... */
|
2012-10-04 17:42:49 -04:00
|
|
|
wl_connection_flush(display->connection);
|
2011-01-22 20:41:07 +01:00
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
if (wl_list_empty(&queue->event_list) &&
|
|
|
|
|
pthread_equal(display->display_thread, pthread_self())) {
|
|
|
|
|
len = wl_connection_read(display->connection);
|
|
|
|
|
if (len == -1) {
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
while (len >= 8) {
|
|
|
|
|
size = queue_event(display, len);
|
|
|
|
|
if (size == 0)
|
|
|
|
|
break;
|
|
|
|
|
len -= size;
|
|
|
|
|
}
|
|
|
|
|
} else if (wl_list_empty(&queue->event_list)) {
|
|
|
|
|
pthread_cond_wait(&queue->cond, &display->mutex);
|
2012-10-04 17:42:49 -04:00
|
|
|
}
|
2011-10-20 15:05:11 -04:00
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
while (!wl_list_empty(&queue->event_list))
|
|
|
|
|
dispatch_event(display, queue);
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_unlock(&display->mutex);
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WL_EXPORT int
|
|
|
|
|
wl_display_dispatch(struct wl_display *display)
|
|
|
|
|
{
|
|
|
|
|
display->display_thread = pthread_self();
|
2012-10-04 17:34:18 -04:00
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
return wl_display_dispatch_queue(display, &display->queue);
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-04 16:54:22 -04:00
|
|
|
WL_EXPORT int
|
2011-05-10 17:51:52 +01:00
|
|
|
wl_display_flush(struct wl_display *display)
|
|
|
|
|
{
|
2012-10-04 17:42:49 -04:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
|
|
|
|
|
ret = wl_connection_flush(display->connection);
|
|
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
|
|
|
|
|
|
|
|
|
return ret;
|
2011-05-10 17:51:52 +01:00
|
|
|
}
|
|
|
|
|
|
2009-09-18 09:49:21 -04:00
|
|
|
WL_EXPORT void
|
2010-08-17 21:23:10 -04:00
|
|
|
wl_proxy_set_user_data(struct wl_proxy *proxy, void *user_data)
|
2009-09-18 09:49:21 -04:00
|
|
|
{
|
2010-08-10 14:02:48 -04:00
|
|
|
proxy->user_data = user_data;
|
2009-09-18 09:49:21 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WL_EXPORT void *
|
2010-08-17 21:23:10 -04:00
|
|
|
wl_proxy_get_user_data(struct wl_proxy *proxy)
|
2009-09-18 09:49:21 -04:00
|
|
|
{
|
2010-08-10 14:02:48 -04:00
|
|
|
return proxy->user_data;
|
2009-09-18 09:49:21 -04:00
|
|
|
}
|
2012-04-27 11:31:07 -04:00
|
|
|
|
|
|
|
|
WL_EXPORT uint32_t
|
|
|
|
|
wl_proxy_get_id(struct wl_proxy *proxy)
|
|
|
|
|
{
|
|
|
|
|
return proxy->object.id;
|
|
|
|
|
}
|
2012-05-29 17:37:02 +02:00
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
|
|
|
|
|
WL_EXPORT void
|
|
|
|
|
wl_proxy_set_queue(struct wl_proxy *proxy, struct wl_event_queue *queue)
|
|
|
|
|
{
|
|
|
|
|
proxy->queue = queue;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-29 17:37:02 +02:00
|
|
|
WL_EXPORT void
|
|
|
|
|
wl_log_set_handler_client(wl_log_func_t handler)
|
|
|
|
|
{
|
|
|
|
|
wl_log_handler = handler;
|
|
|
|
|
}
|