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>
wl_connection_read() assumes that the caller dispatched all messages
before calling it. wl_buffer_put_iov() does only provide enough room so we
fill the buffer. So the only case when the buffer overflows, is when a
previous read filled up the buffer but we couldn't parse a single message
from it. In this case, the client sent a message bigger than our buffer
and we should return an error and close the connection.
krh: Edited from Davids original patch to just check that the buffer
isn't full before we try reading into it.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We rely on well-defined unsigned overflow behaviour so let's make the
index fields actually unsigned. Signed ints aren't guaranteed to have the
behavior we want (could be either ones or twos complement).
If we read more FDs than we have room for, we currently leak FDs because
we overwrite previous still pending FDs. Instead, we do now close incoming
FDs if the buffer is full and return EOVERFLOW.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Same problem as we had with close_fds(). We cannot rely on the fds_out
buffer being filled with less than MAX_FDS_OUT file descriptors.
Therefore, write at most MAX_FDS_OUT file-descriptors to the outgoing
buffer.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Same problem as with outgoing FDs. We need to close these on shutdown,
otherwise we leak open file descriptors.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If we push two messages via wl_connection_write() and both messages
contain more than MAX_FDS_OUT file-descriptors combined, then
wl_connection_flush() will write only MAX_FDS_OUT of them, but close all
pending ones, too.
Furthermore, close_fds() will copy more FDs out of the buffer than it can
hold and cause a buffer overflow. Therefore, we simply pass a maximum
limit to close_fds().
During shutdown, we simply close all available FDs.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
When destroying a wl_connection object, there might still be data in the
queue. We would leak open file-descriptors so we must close them.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If we cannot increase the array for new entries, we now return 0 instead
of accessing invalid memory.
krh: Edited to return 0 on failure instead. In the initialization path,
we call wl_map_insert_new() to insert NULL at index 0, which also returns
0 but not as an error. Since we do that up front, every other case of
returning 0 is an unambiguous error.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We might have to perform memory allocations in wl_array_copy(), so catch
out-of-memory errors in wl_array_add() and return -1 before changing any
state.
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>
Also, now doxygen is mandatory for building the documentation (looks
reasonable because both man-pages and publican will need it).
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.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>
The xsl translation from the protocol xml to publican would create only
one paragraph for all the text in a description. Make it generate one
paragraph for each block of text separated by two consecutive line
breaks instead.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
This moves desc as first argument of desc_dump().
Description writing was broken on i586 because desc_dump() used
va_arg() after a vsnprintf() call to find the last argument.
But after calling a function with a va_arg argument, this arguments is
undefined.
For now only Wayland Client API is described on that chapter, which is
extracted via doxygen on ./src/wayland-client.h. We apply a stylesheet
(doxygen-to-publican) on doxygen output so it becomes docbook valid.
Now all we need to do is populate that header while developing in order to
grow a decent documentation. So please use it!
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
This way looks more pretty, in particular for the Appendix which spawns a big
subsections chain.
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.
We can't use the same behaviour in both the client and the server. In the
client this is a wl_proxy pointer in the server it's a pointer to the
uint32_t object id. This doesn't fix the problem, but it's a slightly
more useful default, since we typically use WAYLAND_DEBUG on the client.
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().
Explicitly say what happens with the wl_buffer.release event, if you
attach several wl_buffers without a commit in between.
Reported-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The previous clarification did not follow the current implementation in
Weston, where when a surface stops being a cursor or an icon, it becomes
a plain unmapped surface again.
Rewrite the related paragraphs, and fix some typos while at it.
For start drag, make it explicit of which surface argument we are
talking about.
v2:
Make the input region undefined when the use ends. Most likely no-one
will re-use these surfaces for anything else than the same use case, so
leave some slack for the implementations to avoid useless work on
resetting the regions.
Reported-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Spell out exactly when a client may re-use a wl_buffer or its backing
storage. Mention the optimization for GL-compositor with wl_shm-clients.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This change breaks the protocol.
The current protocol is racy in that updates to surface content and
surface state (e.g. damage, input and opaque regions) are not guaranteed
to happen at the same time. Due to protocol buffering and handling
practices, the issues are very hard to trigger.
Committing damage to a surface at arbitrary times makes it hard to
track when the wl_buffer is being read by the server, and when it is
safe to overwrite (the case of wl_shm with a single buffer reused
constantly).
This protocol change introduces the concept of double-buffered state.
Such state is accumulated and cached in the server, unused, until the
final commit request. The surface will receive its new content and apply
its new state atomically.
A wl_surface.commit request is added to the protocol. This is thought to
be more clear, than having wl_surface.attach committing implicitly, and
then having another request to commit without attaching, as would be
required for a GL app that wants to change e.g. input region without
redrawing.
When these changes are implemented, clients do not have to worry about
ordering damage vs. input region vs. attach vs. ... anymore. Clients set
the state in any order they want, and kick it all in with a commit.
The interactions between wl_surface.attach, (wl_surface.commit,)
wl_buffer.release, and wl_buffer.destroy have been undocumented. Only
careful inspection of the compositor code has told when a wl_buffer is
free for re-use, especially for wl_shm and wrt. wl_surface.damage.
Try to clarify how it all should work, and what happens if the wl_buffer
gets destroyed.
An additional minor fix: allow NULL argument to
wl_surface.set_opaque_region. The wording in the documentation already
implied that a nil region is allowed.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
In most cases the pointer equality test is sufficient. However, in
some cases, depending on how things are split across shared objects,
we can end up with multiple instances of the interface metadata
constants. So if the pointers match, the interfaces are equal, if
they don't match we have to compare the interface names.
Replace the outdated section about drag and drop support with a
rewritten section covering the data source/offer mechanism and
wl_data_device, explaining how selection and drag ang drop works.
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.
This makes the scanner generate the code and meta data to send the
interface name and version when we pass a typeless new_id. This way, the
generic factory mechanism provided by wl_display.bind can be provided by
any interface.
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.
The update callback for the file descriptors was always a bit awkward and
un-intuitive. The idea was that whenever the protocol code needed to
write data to the fd it would call the 'update' function. This function
would adjust the mainloop so that it polls for POLLOUT on the fd so we
can eventually flush the data to the socket.
The problem is that in multi-threaded applications, any thread can issue
a request, which writes data to the output buffer and thus triggers the
update callback. Thus, we'll be calling out with the display mutex
held and may call from any thread.
The solution is to eliminate the udpate callback and just require that
the application or server flushes all connection buffers before blocking.
This turns out to be a simpler API, although we now require clients to
deal with EAGAIN and non-blocking writes. It also saves a few syscalls,
since the socket will be writable most of the time and most writes will
complete, so we avoid changing epoll to poll for POLLOUT, then write and
then change it back for each write.
