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.
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>
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.
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>
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.
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.
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.
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
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>
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.
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>
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>
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.
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>
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>
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>
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>
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 33b7637b45.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
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.
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.
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>
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>
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>
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>
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>
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.
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.
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.
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 9de9e39f87
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().
On the client side where we queue up multiple events before dispatching, we
need to look up the receiving proxy and argument proxies immediately before
calling the handler. Between queueing up multiple events and eventually
invoking the handler, previous handlers may have destroyed some of the
proxies.
The only way to make the global object listener interface thread safe is to
make it its own interface and make different listeners different wl_proxies.
The core of the problem is the callback we do when a global show up or
disappears, which we can't do with a lock held. On the other hand we can't
iterate the global list or the listener list without a lock held as new
globals or listeners may come and go during the iteration.
Making a copy of the list under the lock and then iterating after dropping
the lock wont work either. In case of the listener list, once we drop the
lock another thread may unregister a listener and destroy the callbackk
data, which means that when we eventually call that listener we'll pass it
free memory and break everything.
We did already solve the thread-safe callback problem, however. It's what
we do for all protocol events. So we can just make the global registry
functionality its own new interface and give each thread its own proxy.
That way, the thread will do its own callbacks (with no locks held) and
destroy the proxy when it's no longer interested in wl_registry events.
We used to special case this because of the untyped new-id argument in
the bind request. Now that the scanner can handle that, we can
remove the special case.
Switching to the generated stubs does bring an API change since we now
also take the interface version that the client expects as an argument.
Previously we would take this from the interface struct, but the
application may implement a lower version than what the interface struct
provides. To make sure we don't try to dispatch event the client
doesn't implement handlers for, we have to use a client supplied version
number.
