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.
When integrating the wayland event-loop into another event-loop, we
currently have no chance of checking whether there are pending idle
sources that have to be called. This patch exports the
"dispatch_idle_sources()" call so other event loops can call this before
going to sleep. This is what wl_event_loop_dispatch() currently does so we
simply allow external event-loops to do the same now.
To avoid breaking existing applications, we keep the call to
dispatch_idle_sources() in wl_event_loop_dispatch() for now. However, if
we want we can remove this later and require every application to call
this manually. This needs to be discussed, but the overhead is negligible
so we will probably leave it as it is.
This finally allows to fully integrate the wayland-server API into
existing event-loops without any nasty workarounds.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
wl_client_add_resource() used to return no error even though the new
resource wasn't added to the client. This currently makes it very easy to
DOS weston by simply posting thousands of "create_surface" requests with
an invalid ID. Weston simply assumes the wl_client_add_resource() request
succeeds but will never destroy the surface again as the "destroy" signal
is never called (because the surface isn't linked into the wl_map).
This change makes wl_client_add_resource() return the new ID of the added
object and 0 on failure. Servers (like weston) can now correctly
immediately destroy the surface when this call fails instead of leaving
the surface around and producing memory-leaks.
Instead of returning -1 on failure and 0 on success, I made it return the
new ID as this seems more appropriate. We can directly use it when calling
it with new_id==0.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
There is really no need to increment "n" if we never read the value. The
do-while() loop overwrites the value before it is read the first time.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Expose these to other files using wayland-private.h, so wayland-client.c
can walk NULLables properly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If a new object id arrives ensure that there is an empty array entry
created, otherwise we might get out of sync for new ids if object isn't
created by interface implementation.
Creation of new client resources was silently ignored when
wl_client_add_resource() was used on server side and new object id was out
of range.
An error is now send out to the client in such case.
Also changed error message in wl_client_add_object, since
wl_map_insert_at() returns -1 only at invalid new id.
I've found a bug during wayland exploration - if you make two
drag'n'drops in weston client example, dnd - weston crashes with
segfault. I've tried to investigate it and found a problem.
In function drag_grab_button we first call data_device_end_drag_grab,
which sets seat->drag_data_source to NULL. Then we remove
listener from list only if drag_data_source is not NULL.
So if client will not free wl_data_source and start another drag'n'drop,
after the first one. Then two wl_data_source structures will be
free'd on client exit (let's name them s1 and s2).
next and prev pointer of
wl_data_source.resource.destroy_signal.listener_list in both
wl_data_source structures will be seat->drag_data_source_listener,
but next and prev in seat->drag_data_source_listener.link point
to listener_list in s2.
So if you try to iterate over listener_list in s1
then you get drag_data_source_listener as first item and
(struct wl_listener *)(&s2.resource.destroy_signal.listener_list)
Iteration over that list occurs in
wl_resource_destroy->destroy_resource->wl_signal_emit->wl_signal_emit
and try to call function at address of wl_resource->client, so
weston segfaults there.
This makes wl_seat_set_keyboard similar to wl_seat_set_pointer in that
it's a no-op, if you try to set keyboard to NULL when it already is
NULL, instead of refusing to set it to NULL ever.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Most of the time it does not make sense to pass a NULL object, string, or array
to a protocol request. This commit adds an explicit “allow-null” attribute
to mark the request arguments where NULL makes sense.
Passing a NULL object, string, or array to a protocol request which is not
marked as allow-null is now an error. An implementation will never receive
a NULL value for these arguments from a client.
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Attempting to write anything longer into the embedded char
array would create a non-null-terminated string, and all
later reads would run off the end into invalid memory.
This is a hard limitation of AF_LOCAL/AF_UNIX sockets.
Attempting to write anything longer into the embedded char
array would create a non-null-terminated string, and all
later reads would run off the end into invalid memory.
This is a hard limitation of AF_LOCAL/AF_UNIX sockets.
Always unlink() the lock file before closing the file
descriptor for it. Otherwise, there is a race like this:
Process A closes fd, releasing the lock
Process B opens the same file, taking the lock
Process A unlinks the lock file
Process C opens the same file, which now no longer exists,
and takes the lock on the newly created lock file
Process B and C both 'own' the same display socket.
unlink()ing while holding the lock is effectively a better
way to release the lock atomically.
When the server send a new object ID, the client used to have to allocate
the proxy manually and without type-safety. We now allocate the proxy
in a client-side post-processing step on the incoming closure.
Provide a slot for keyboard modifier state inside wl_keyboard for
implementations to update, and use this to send wl_keyboard:;modifier
events whenever the keyboard or pointer focus changes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If the data source is destroyed, the corresponding offers may stay around for
a little longer (until the owning client destroys it). When the offer is
finally destroyed, we have to be careful to only remove the source
destroy listener if the source hasn't yet been destroyed.
Thanks to Martin Minarik for tracking down where the corruption happened.
The wl_data_source object used to specify the implementation for data
offers created for it. This means you need a data offer to retrieve the
data from the source, which makes it awkward to use in-process in a
compositor. Now we instead have three virtual functions that can be
connected to a protocol object or in-process data-sources such as an
X server proxy or clipboard.
