summaryrefslogtreecommitdiffstats
path: root/src/wayland-client.c
Commit message (Collapse)AuthorAgeFilesLines
* client: Include poll.h instead of sys/poll.hJonas 'Sortie' Termansen2014-01-171-1/+1
| | | | POSIX mandates the poll.h header as the standard location of poll(2).
* client: Handle EINTR in wl_display_dispatch_queue()Kristian Høgsberg2013-12-091-1/+5
| | | | | | Restart the poll() if we take a signal. This is easily triggered in an application that ends up blocking in eglSwapBuffers(), and causes EGL to fail to allocate a back buffer.
* doc: Fix spelling of parametersJonas Ådahl2013-12-091-2/+2
| | | | Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* client: Make wl_proxy_set_queue() with NULL revert to default queueNeil Roberts2013-12-041-1/+4
| | | | | | | | | | | | | | This will be useful in order to implement the EGL_WL_create_wayland_buffer_from_image extension. The buffers created within Mesa's Wayland platform are created using the the wl_drm object as a proxy factory which means they will be set to use Mesa's internal event queue. However, these buffers will be owned by the client application so they ideally need to use the default event loop. This function provides a way to set the proxy's event queue back to the default. krh: Edited from Neils original patch to just use wl_proxy_set_queue() with a NULL argument instead of introducing a new function.
* client: Introduce functions to allocate and marshal proxies atomicallyKristian Høgsberg2013-11-151-54/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The server requires clients to only allocate one ID ahead of the previously highest ID in order to keep the ID range tight. Failure to do so will make the server close the client connection. However, the way we allocate new IDs is racy. The generated code looks like: new_proxy = wl_proxy_create(...); wl_proxy_marshal(proxy, ... new_proxy, ...); If two threads do this at the same time, there's a chance that thread A will allocate a proxy, then get pre-empted by thread B which then allocates a proxy and then passes it to wl_proxy_marshal(). The ID for thread As proxy will be one higher that the currently highest ID, but the ID for thread Bs proxy will be two higher. But since thread B prempted thread A before it could send its new ID, B will send its new ID first, the server will see the ID from thread Bs proxy first, and will reject it. We fix this by introducing wl_proxy_marshal_constructor(). This function is identical to wl_proxy_marshal(), except that it will allocate a wl_proxy for NEW_ID arguments and send it, all under the display mutex. By introducing a new function, we maintain backwards compatibility with older code from the generator, and make sure that the new generated code has an explicit dependency on a new enough libwayland-client.so. A virtual Wayland merit badge goes to Kalle Vahlman, who tracked this down and analyzed the issue. Reported-by: Kalle Vahlman <kalle.vahlman@movial.com>
* client: Fix handling display->reader_count if poll failsNeil Roberts2013-09-251-1/+3
| | | | | | | | | | In wl_display_dispatch_queue, if poll fails then it would previously return immediately and leak a reference in display->reader_count. Then if the application ignores the error and tries to read again it will block forever. This can happen for example if the poll fails with EINTR which the application might consider to be a recoverable error. This patch makes it cancel the read so the reader_count will be decremented when poll fails.
* client: fix an inconsistency in documentationChang Liu2013-09-211-1/+1
| | | | | The errno is set to EAGAIN when there are undispatched events, according to L1066 of wayland-client.c.
* Add support for client-side language bindingsJason Ekstrand2013-08-191-9/+81
| | | | | | | This commit adds support for language bindings on the client half of the library. The idea is the same as for server-side dispatchers. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
* wayland-client: Add wl_proxy_get_listenerRob Bradford2013-08-121-0/+19
| | | | | | This is the mirror function to wl_proxy_add_listener and is useful inside client libraries to differentiate events on listeners for which multiple proxies have been created.
* client: Improve spelling and grammar in commentsBryce W. Harrington2013-08-081-6/+6
| | | | Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
* client: Simply wl_display_dispatch_queue_pending() and fix return valueJiergir Ogoerg2013-07-291-7/+4
| | | | | We're supposed to return number of events dispatched on success, not 0. Refactor to avoid goto and just return ret.
* wayland-client: Handle potential NULL-derefKristian Høgsberg2013-07-131-0/+2
| | | | | Instead, return -1 on out-of-memory. errno will be set to ENOMEM by the failing malloc.
* wayland-server: Don't close display fd in fatal error handlerKristian Høgsberg2013-07-091-4/+1
| | | | | | | We can't do that there, we have to make sure it stays a valid fd until the application calls wl_display_disconnect(). Otherwise the application may end up poll()ing on a stale or wrong fd in case another part of the application (or another thread) triggered a fatal error.
* wayland-server: Return 0 from read_events() in case of EAGAINKristian Høgsberg2013-07-091-2/+4
| | | | | | | | | Getting no data from the socket is not an error condition. This may happen in case of calling prepare_read() and then read_events() with no other pending readers and no data in the socket. In general, read_events() may not queue up events in the given event queue. From a given threads point of view it doesn't matter whether events were read and put in a different event queue or no events were read at all.
* wayland-client: Treat EOF when reading the wayland socket as an errorNeil Roberts2013-07-091-0/+8
| | | | | | | | | | | | | | | | | If EOF is encountered while reading from the Wayland socket, make wl_display_read_events() return -1 so that it will be treated as an error. The documentation for this function states that it will set errno when there is an error so it additionally makes up an errno of EPIPE. If we don't do this then when the compositor quits the Wayland socket will be become ready for reading but wl_display_dispatch will do nothing which typically makes the application take up 100% CPU. In particular eglSwapBuffers will likely get stuck in an infinite busy loop because it repeatedly calls wl_display_dispatch_queue while it waits for the frame callback. https://bugzilla.gnome.org/show_bug.cgi?id=703892
* server: Make wl_object and wl_resource opaque structsKristian Høgsberg2013-07-021-2/+3
| | | | | | | | | | With the work to add wl_resource accessors and port weston to use them, we're ready to make wl_resource and wl_object opaque structs. We keep wl_buffer in the header for EGL stacks to use, but don't expose it by default. In time we'll remove it completely, but for now it provides a transition paths for code that still uses wl_buffer. Reviewed-by: Jason Ekstrand<jason@jlekstrand.net>
* client: Add wl_display_prepare_read() API to relax thread model assumptionsKristian Høgsberg2013-06-171-51/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current thread model assumes that the application or toolkit will have one thread that either polls the display fd and dispatches events or just dispatches in a loop. Only this main thread will read from the fd while all other threads will block on a pthread condition and expect the main thread to deliver events to them. This turns out to be too restrictive. We can't assume that there always will be a thread like that. Qt QML threaded rendering will block the main thread on a condition that's signaled by a rendering thread after it finishes rendering. This leads to a deadlock when the rendering threads blocks in eglSwapBuffers(), and the main thread is waiting on the condition. Another problematic use case is with games that has a rendering thread for a splash screen while the main thread is busy loading game data or compiling shaders. The main thread isn't responsive and ends up blocking eglSwapBuffers() in the rendering thread. We also can't assume that there will be only one thread polling on the file descriptor. A valid use case is a thread receiving data from a custom wayland interface as well as a device fd or network socket. The thread may want to wait on either events from the wayland interface or data from the fd, in which case it needs to poll on both the wayland display fd and the device/network fd. The solution seems pretty straightforward: just let all threads read from the fd. However, the main-thread restriction was introduced to avoid a race. Simplified, main loops will do something like this: wl_display_dispatch_pending(display); /* Race here if other thread reads from fd and places events * in main eent queue. We go to sleep in poll while sitting on * events that may stall the application if not dispatched. */ poll(fds, nfds, -1); /* Race here if other thread reads and doesn't queue any * events for main queue. wl_display_dispatch() below will block * trying to read from the fd, while other fds in the mainloop * are ignored. */ wl_display_dispatch(display); The restriction that only the main thread can read from the fd avoids these races, but has the problems described above. This patch introduces new API to solve both problems. We add int wl_display_prepare_read(struct wl_display *display); and int wl_display_read_events(struct wl_display *display); wl_display_prepare_read() registers the calling thread as a potential reader of events. Once data is available on the fd, all reader threads must call wl_display_read_events(), at which point one of the threads will read from the fd and distribute the events to event queues. When that is done, all threads return from wl_display_read_events(). From the point of view of a single thread, this ensures that between calling wl_display_prepare_read() and wl_display_read_events(), no other thread will read from the fd and queue events in its event queue. This avoids the race conditions described above, and we avoid relying on any one thread to be available to read events.
* Add support for flags in the wl_map API and add a WL_MAP_ENTRY_LEGACY flagJason Ekstrand2013-06-051-6/+6
| | | | | | | | The implementation in this commit allows for one bit worth of flags. If more flags are desired at a future date, then the wl_map implementation will have to change but the wl_map API will not. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
* Add a "side" field and some sanity checks to wl_map.Jason Ekstrand2013-06-051-6/+4
| | | | | | | | | | | | | | | | | | | | The original wl_map implementation did no checking to ensures that ids fell on the correct side of the WL_SERVER_ID_START line. This meant that a client could send the server a server ID and it would happily try to use it. Also, there was no distinction between server-side and client-side in wl_map_remove. Because wl_map_remove added the entry to the free list regardless of which side it came from, the following set of actions would break the map: 1. Client creates a bunch of objects 2. Client deletes one or more of those objects 3. Client does something that causes the server to create an object Because of the problem in wl_map_remove, the server would take an old client-side id, apply the WL_SERVER_ID_START offset, and try to use it as a server-side id regardless of whether or not it was valid. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
* wayland-client: Avoid null dereference when handling deletionRob Bradford2013-04-041-1/+5
| | | | | | | If an unknown id is deleted then the lookup in the map will return NULL and so we should avoid dereferencing that. As this is unexpected behaviour log a message about the problem too.
* docs: Document non-blocking behaviour of wl_display_flush()Kristian Høgsberg2013-04-021-1/+6
|
* Change wl_closure_invoke to take an opcode instead of an actual function pointerJason Ekstrand2013-03-181-2/+2
| | | | Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
* client: Invoke new_id closure arguments as pointers instead of integersJonas Ådahl2013-03-171-1/+1
| | | | | | | | | | | | | | | This commit adds a flags parameter to wl_closure_invoke(). The so far added flags are ment to specify if the invokation is client side or server side. When on the server side, closure arguments of type 'new_id' should be invoked as a integer id while on the client side they should be invoked as a pointer to a proxy object. This fixes a bug happening when the address of a client side 'new_id' proxy object did not fit in a 32 bit integer. krh: Squashed test suite compile fix from Jason Ekstrand. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* client: Check reference count only for destroyed proxiesJonas Ådahl2013-03-171-3/+3
| | | | | | | | | | | | | | | | | | | The llvm static analyzer tool reported "Use of memory after it is freed" in dispatch_event() because the proxy is used after being freed if the reference count reaches zero without the destroyed flag being set. This would never happen in practice because the owner of the proxy object always holds a reference until calling wl_proxy_destroy() which would also set the destroyed flag. Since this is the case, it is safe to do the reference count check only if the destroyed flag is set, as it can never reach zero if not. This commit doesn't change the behavior of the function, but makes the static analyzer more happy. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=61385 Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* Clean up and refactor wl_closure and associated functionsJason Ekstrand2013-02-261-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | The primary purpose of this patch is to clean up wl_closure and separate closure storage, libffi, and the wire format. To that end, a number of changes have been made: - The maximum number of closure arguments has been changed from a magic number to a #define WL_CLOSURE_MAX_ARGS - A wl_argument union has been added for storing a generalized closure argument and wl_closure has been converted to use wl_argument instead of the combination of libffi, the wire format, and a dummy extra buffer. As of now, the "extra" field in wl_closure should be treated as bulk storage and never direclty referenced outside of wl_connection_demarshal. - Everything having to do with libffi has been moved into wl_closure_invoke and the convert_arguments_to_ffi helper function. - Everything having to do with the wire format has been restricted to wl_connection_demarshal and the new static serialize_closure function. The wl_closure_send and wl_closure_queue functions are now light wrappers around serialize_closure. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
* client: add wl_proxy_get_class()Pekka Paalanen2013-02-261-0/+12
| | | | | | | This is a useful shorthand for client application debugging macros, since you can ask the object class from the object itself. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
* client: Add \since tag for wl_display_dispatch_queue_pending() documentationKristian Høgsberg2012-11-301-0/+1
|
* client: Don't cancel a roundtrip when any event is receivedJonas Ådahl2012-11-271-1/+4
| | | | | | | | | | | | | Since wl_display_dispatch() returns the number of processed events or -1 on error, only cancel the roundtrip if an -1 is returned. This also fixes a potential memory corruption bug happening when wl_display_roundtrip() does an early return and the callback later writes to the then out of scope stack allocated `done' parameter. Introduced by 33b7637b4500a682018b503837b8aca9afae36f2. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* doc: Fix typosTiago Vignatti2012-11-231-2/+2
| | | | Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
* client: Add an entry point for dispatching a queue without blockingAnder Conselvan de Oliveira2012-11-231-0/+19
| | | | | | | | On the client side EGL, all the wl_buffer.release events need to be processed before buffer allocation, otherwise a third buffer might be allocated unnecessarily. However, the buffer allocation should not block in the case no event was received. In order to do that, a non-blocking queue dispatch function is needed.
* debug: Allow WAYLAND_DEBUG=server/client for server/client side only debugKristian Høgsberg2012-11-211-1/+1
| | | | | | | By default the server will dump protocol for both the server and its clients when run with WAYLAND_DEBUG=1. That's still the case, but it now also understands WAYLAND_DEBUG=client or WAYLAND_DEBUG=server, which will only enable debug dumping on either client or server side.
* client: Fix source comment typosMartin Olsson2012-11-141-3/+3
|
* client: Keep track of proxy validity and number of reference holdersJonas Ådahl2012-11-051-20/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | When events are queued, the associated proxy objects (target proxy and potentially closure argument proxies) are verified being valid. However, as any event may destroy some proxy object, validity needs to be verified again before dispatching. Before this change this was done by again looking up the object via the display object map, but that did not work because a delete_id event could be dispatched out-of-order if it was queued in another queue, causing the object map to either have a new proxy object with the same id or none at all, had it been destroyed in an earlier event in the queue. Instead, make wl_proxy reference counted and increase the reference counter of every object associated with an event when it is queued. In wl_proxy_destroy() set a flag saying the proxy has been destroyed by the application and only free the proxy if the reference counter reaches zero after decreasing it. Before dispatching, verify that a proxy object still is valid by checking that the flag set in wl_proxy_destroy() has not been set. When dequeuing the event, all associated proxy objects are dereferenced and free:ed if the reference counter reaches zero. As proxy reference counter is initiated to 1, when dispatching an event it can never reach zero without having the destroyed flag set. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* doc: Clarify documentation about dispatching event queuesAnder Conselvan de Oliveira2012-10-191-2/+56
| | | | | Clarify on what cases each of the dispatching functions may block, what is the main thread and add some real world examples.
* doc: Update wl_display_get_error() documentationAnder Conselvan de Oliveira2012-10-171-2/+8
|
* doc: Add doxygen documentation to wl_display_get_error()Ander Conselvan de Oliveira2012-10-161-0/+7
|
* doc: Document change of return value of dispatch functionsAnder Conselvan de Oliveira2012-10-161-2/+3
|
* doc: Document the restriction of destroying queues before the displayAnder Conselvan de Oliveira2012-10-161-0/+4
|
* doc: Put wl_display_flush() documentation in the right placeAnder Conselvan de Oliveira2012-10-161-12/+12
| | | | It seems a rebase error caused it to end up in the wrong place.
* wayland-client: forward fatal errors to callerDavid Herrmann2012-10-151-19/+80
| | | | | | | | | If any callback or helper function fails with a fatal error, we now set the last_error flag and prevent all further I/O on the wl_display. We wake up all sleeping event-queues and notify the caller that they should shutdown wl_display. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
* wayland: Take ownership of fd in wl_display_connect_to_fd()Kristian Høgsberg2012-10-151-11/+9
| | | | | This means we're free to close it when we want, which we'll use to wake up the main thread if we hit an error in a different thread.
* wayland-client: link all event-queues of each display into a listDavid Herrmann2012-10-151-3/+17
| | | | | | | | | | | We need access to all event-queues of a single wl_display object. For instance during connection-errors, we need to be able to wake up all event queues. Otherwise, they will be stuck waiting for incoming events. The API user is responsible to keep a wl_display object around until all event-queues that were created on it are destroyed. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
* wayland-client: add wl_display_get_error()David Herrmann2012-10-151-3/+36
| | | | | | | | A server may asynchronously send errors via wl_display.error() events. Instead of aborting we now the a "last_error" flag inside of wl_display objects. The user can retrieve these via wl_display_get_error(). Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
* doc: Improve libwayland-client doxygen documentationAnder Conselvan de Oliveira2012-10-151-7/+46
| | | | | Document wl_proxy, wl_display and wl_event_queue classes and add a description to all public entry points. Also fix some typos.
* doc: Add some doxygen documentation to wayland-client entry pointsAnder Conselvan de Oliveira2012-10-151-1/+169
| | | | | | | | | Add some brief documentation for the public libwayland-client entry points. This is by no means complete, some functions are still undocumented and some might need extra information. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
* client: Return number of events dispatched from dispatch functionsKristian Høgsberg2012-10-151-3/+3
| | | | | | | | | | | | | | | | To let clients determine whether any events were dispatched, we return the number of dispatched events. An event source with an event queue (such as wl_display or an X connection) may queue up event as a result of processing a different event source (data on a network socket, timerfd etc). After dispatching data from fd (or just before blocking) we have to check such event sources, which is what wl_event_source_check() is used for. A checked event source will have its handler called with mask=0 just before blocking. If any work is done in any of these handlers, we have to check all the checked sources again, since the work could have queued up events in a different source. This is why the event handlers must return a positive number if events were handled. Which in turn is why we need the wl_display dispatch functions to return that as well.
* client: Add wl_display_dispatch_pending() for dispatching without readingKristian Høgsberg2012-10-151-6/+21
| | | | | | | | | | | | | | If the main thread ends up dispatching a non-main queue, and not in a wl_display_dispatch() callback, we may queue up main queue events and read all data from the socket fd. When we get back to the main loop, the socket fd is no longer readable and nothing will trigger dispatching of the queued up events. The new function wl_display_dispatch_pending() will dispatch any pending events, but not attempt to read from the socket. Clients that integrate the wayland socket fd into a main loop should call wl_display_dispatch_pending() and then wl_display_flush() before going back to blocking in poll(2) or similar mechanism.
* client: Discard proxies with no implementation at dispatch timeKristian Høgsberg2012-10-111-2/+3
| | | | | | | | We need to queue up events even if a proxy doesn't have an implementation (listener). In case of server created new objects, the client haven't had a chance to set the listener when the first events to the new object come in. So now we always queue up events and discard them at dispatch time if they don't have a listener at that point.
* client: Don't forget to init and destroy mutexKristian Høgsberg2012-10-111-0/+2
| | | | | These chunks were dropped at some point, thanks to David Herrmann for spotting the omission.
* client: Fix double locking bugAnder Conselvan de Oliveira2012-10-111-3/+2
| | | | | | | | | | | | | | | | | | | | The function wl_proxy_create_for_id() would try to acquire the display lock, but the only call path leading to it would call it with the lock already acquired. This patch removes the attempt to acquire the lock and makes the function static. It was exported before because client had to create proxy's manually when the server sent a new object id, but since commit 9de9e39f [1] this is no longer necessary. [1] commit 9de9e39f87adfce1ea9755e394928756254c0ba2 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Thu Jun 28 22:01:58 2012 -0400 Allocate client proxy automatically for new objects v2: Change the right function. Previous patch changed wl_proxy_create() instead of wl_proxy_create_for_id().