This fixes a validation error in the documentation which are not fatal.
The idea is the same as in 12ec67a ("server: document listener fields
and a vfunc"), which seems to have missed the reference to the
wl_protocol_logger_func_t from the note in wl_log_func_t.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Adding these simple documentation comments allows us to have meaningful
link targets in the generated API documentation. That will help getting
rid of broken links which cause XML validation to fail.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
$ meson compile -C build -v xml-Server-doc
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /home/pq/git/wayland/build -v doc/doxygen/xml/Server/combine.xslt doc/doxygen/xml/Server/index.xml
ninja: Entering directory `/home/pq/git/wayland/build'
[1/1] /home/pq/git/wayland/doc/doxygen/gen-doxygen.py --builddir=doc/doxygen/xml/Server --section=Server --output-format=xml doc/doxygen/wayland.doxygen ../doc/doxygen/../../src/wayland-util.h ../doc/doxygen/../../src/event-loop.c ../doc/doxygen/../../src/wayland-server.c ../doc/doxygen/../../src/wayland-server.h ../doc/doxygen/../../src/wayland-server-core.h ../doc/doxygen/../../src/wayland-shm.c
/home/pq/git/wayland/src/wayland-server-core.h:394: warning: explicit link request to 'wl_signal_add' could not be resolved
I don't know why, but the "explicit link" mark-up fails, while the
automatic link mark-up works. This warning disappears.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Shared memory buffers are currently tied to the lifetime of their
underlying wl_buffer resource. This becomes problematic when the client
destroys the resource after committing new state which references the
wl_buffer because a compositor might have to defer applying the commit.
This commit adds methods to keep the wl_shm_buffer alive longer than the
underlying resource. This implicitly also keeps the buffer pool alive
and because the wl_shm_buffer uses offsets into the pool, it even works
when the underlying storage gets remapped somewhere else, which can
happen when the client resizes the pool.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Makes it possible to e.g. `call wl_client_get_credentials` with a `const
struct wl_client *` from a global filter callback.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
When using fixed size connection buffers, if either the client or the
server is sending requests faster than the other end can cope with, the
connection buffers will fill up, eventually killing the connection.
This can be a problem for example with Xwayland mapping a lot of
windows, faster than the Wayland compositor can cope with, or a
high-rate mouse flooding the Wayland client with pointer events.
To avoid the issue, resize the connection buffers dynamically when they
get full.
Both data and fd buffers are resized on demand.
The default max buffer size is controlled via the wl_display interface
while each client's connection buffer size is adjustable for finer
control.
The purpose is to explicitly have larger connection buffers for specific
clients such as Xwayland, or set a larger buffer size for the client
with pointer focus to deal with a higher input events rate.
v0: Manuel:
Dynamically resize connection buffers - Both data and fd buffers are
resized on demand.
v1: Olivier
1. Add support for unbounded buffers on the client side and growable
(yet limited) connection buffers on the server side.
2. Add the API to set the default maximum size and a limit for a given
client.
3. Add tests for growable connection buffers and adjustable limits.
v2: Additional fixes by John:
1. Fix the size calculation in ring_buffer_check_space()
2. Fix wl_connection_read() to return gracefully once it has read up to
the max buffer size, rather than returning an error.
3. If wl_connection_flush() fails with EAGAIN but the transmit
ring-buffer has space remaining (or can be expanded),
wl_connection_queue() should store the message rather than
returning an error.
4. When the receive ring-buffer is at capacity but more data is
available to be read, wl_connection_read() should attempt to
expand the ring-buffer in order to read the remaining data.
v3: Thomas Lukaszewicz <tluk@chromium.org>
Add a test for unbounded buffers
v4: Add a client API as well to force bounded buffers (unbounded
by default (Olivier)
v5: Simplify ring_buffer_ensure_space() (Sebastian)
Co-authored-by: Olivier Fourdan <ofourdan@redhat.com>
Co-authored-by: John Lindgren <john@jlindgren.net>
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: John Lindgren <john@jlindgren.net>
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/237
The only way to attach some data to a wl_client seems to be setting up a
destroy listener and use wl_container_of. Let's make it straight forward
to attach some data.
Having an explicit destroy callback for the user data makes managing the
user data lifetime much more convenient. All other callbacks, be they
wl_resource request listeners, destroy listeners or destructors, or
wl_client destroy listeners, can assume that the wl_client user data
still exists if it was set. Otherwise making that guarantee would be
complicated.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
A late-destroy listener for a client is called after all the client's
resources have been destroyed and the destroy callbacks emitted. This
lives in parallel to the existing client destroy listener, called
immediately before the client's objects get destroyed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: wayland/wayland#207
Add a helper to check the advertised version of a global. This can
be handy when checking whether a compositor feature is supported,
instead of having to store the version passed to wl_global_create
separately.
Signed-off-by: Simon Ser <contact@emersion.fr>
wl_signal_emit doesn't handle well situations where a listener removes
another listener. This can happen in practice: wlroots and Weston [1]
both have private helpers to workaround this defect.
wl_signal_emit can't be fixed without breaking the API. Instead,
introduce a new function. Callers need to make sure to always remove
listeners when they are free'd.
[1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/457
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
This can be useful if the compositor wants to call wl_global_destroy() with some
delay but it doesn't have the wl_display object associated with the global,
which is needed to get access to the event loop.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
This commit adds a new wl_global_remove function that just sends a global
remove event without destroying it. See [1] for details.
Removing a global is racy, because clients have no way to acknowledge they
received the removal event.
It's possible to mitigate the issue by sending the removal event, waiting a
little and then destructing the global for real. The "wait a little" part is
compositor policy.
[1]: https://gitlab.freedesktop.org/wayland/wayland/issues/10
Signed-off-by: Simon Ser <contact@emersion.fr>
When implementing a workaround for [1], one needs to accept a global to be
bound even though it has become stale.
Often, a global's user data is free'd when the global needs to be destroyed.
Being able to set the global's user data (e.g. to NULL) can help preventing a
use-after-free.
(The alternative is to make the compositor responsible for keeping track of
stale user data objects via e.g. refcounting.)
[1]: https://gitlab.freedesktop.org/wayland/wayland/issues/10
Signed-off-by: Simon Ser <contact@emersion.fr>
Many languages such as C++ or Rust have an unwinding error-reporting
mechanism. Code in these languages can (and must!) wrap request handling
callbacks in unwind guards to avoid undefined behaviour.
As a consequence such code will detect internal server errors, but have
no way to communicate such failures to the client.
This adds a WL_DISPLAY_ERROR_IMPLEMENTATION error to wl_display so that
such code can notify (and disconnect) clients which hit internal bugs.
While servers can currently abuse other wl_display errors for the same
effect, adding an explicit error code allows clients to tell the
difference between errors which are their fault and errors which are the
server's fault. This is particularly interesting for automated bug
reporting.
v2: Rename error from "internal" to "implementation", in sympathy with
X11's BadImplementation error.
Add more justification in the commit message.
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Bug [1] reported that wl_display_destroy() doesn't destroy clients, so
client socket file descriptors are being kept open until the compositor
process exits.
Patch [2] proposed to destroy clients in wl_display_destroy(). The
patch was not accepted because doing so changes the ABI.
Thus, a new wl_display_destroy_clients() function is added in this
patch. It should be called by compositors right before
wl_display_destroy().
[1] https://bugs.freedesktop.org/show_bug.cgi?id=99142
[2] https://patchwork.freedesktop.org/patch/128832/
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
This documents all the public API related to wl_event_loop and
wl_event_source objects.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
[Pekka: fixed typos pointed by Yong]
[Pekka: fixed typos pointed by Christopher]
Reviewed-By: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
When using a wl_global, a server may need to retrieve the associated
wl_interface and user data.
Add a couple of convenient functions wl_global_get_interface() and
wl_global_get_user_data() for this purpose.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add a new API to let compositor decide whether or not a wl_global
should be advertised to the clients via wl_registry_bind() or
display_get_registry()
By using its own filter, the compositor can decide which wl_global would
be listed to clients.
Compositors can use this mechanism to hide their own private interfaces
that regular clients should not use.
- Hiding interfaces that expose compositor implementation details
makes it harder for clients to identify the compositor. Therefore
clients are a little less likely to develop compositor-specific
workarounds instead of reporting problems upstream.
- Hiding can be used to diminish the problems from missing namespacing:
if two compositors happen to use the same named global with
different interfaces for their special-purpose clients, the client
expecting the different interface would probably never see it
advertised.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Commit 596024f728 includes a doc comment
with a link to the wl_client_for_each macro, causing an error when generating
documentation.
Add a doc comment to wl_client_for_each, enabling the hyperlink and removing
the error.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
The new wl_display_add_protocol_logger allows to set a function as
a logger, which will get called when a new request is received or an
event is sent.
This is akin to setting WAYLAND_DEBUG=1, but more powerful because it
can be enabled at run time and allows to show the log e.g. in a UI view.
A test is added for the new functionality.
Signed-off-by: Giulio Camuffo <giulio.camuffo@kdab.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
To complement on the new resource created signal, this allows to
iterate over the existing resources of a client.
Signed-off-by: Giulio Camuffo <giulio.camuffo@kdab.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
[Pekka: added empty lines, init ret in for_each_helper()]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This change allows to add a resource creation listener to a wl_client,
which will be notified when a new resource is created for that client.
The alternative would be to have a per wl_display listener, but i think
that resources are really client specific objects, so it makes sense
to use the wl_client as the context.
Signed-off-by: Giulio Camuffo <giulio.camuffo@kdab.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
[Pekka: added wl_list_remove() in TEST(new_resource).]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This patch chooses the wl_list_for_each-style of iterating over
the clients, instead of using an iterator function, because i think
it is easier to use.
Signed-off-by: Giulio Camuffo <giulio.camuffo@kdab.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Using display object, Emit a signal if a new client is created.
In the server-side, we can get the destroy event of a client,
But there is no way to get the created event of it.
Of course, we can get the client object from the global registry
binding callbacks.
But it can be called several times with same client object.
And even if A client creates display object,
(so there is a connection), The server could not know that.
There could be more use-cases not only for this.
Giulio: a test is added for the new functionality
Signed-off-by: Sung-jae Park <nicesj@nicesj.com>
Signed-off-by: Giulio Camuffo <giulio.camuffo@kdab.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
wayland-server.h: Adjust line breaks between prototypes.
wayland-server-core.h:
Adjust line breaks between prototypes.
Adjust space between splats and identifiers.
Remove unconventional linebreak before first parameter.
Add line breaks after return types.
Remove unnecessary forward declarations, and:
- move 'struct wl_client' declaration close to the dependent typedef
- tastefully move 'wl_shm_buffer_get' to leverage the return type
Replace explicit __attribute__ with WL_PRINTF macro.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Analogous to previous commit but for the server(-core) header.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
This adds an API to get the file descriptor for a client.
The client file descriptor can be used for a wayland compositor to validate
a request from a client if there are any additional information provided from
the client's file descriptor.
For instance, this will be helpful in some linux distributions, in which SELinux
or SMACK is enabled. In those environments, each file (including socket) will have
each security contexts in its inode as xattr member variable. A wayland compositor
can validate a client request by getting the file descriptor of the client and
by checking the security contexts associated with the file descriptor.
Signed-off-by: Sung-Jin Park <input.hacker@gmail.com>
This adds functionality to allow system-level control over handing out
file descriptors for sockets, to allow tighter security when running a
Wayland compositor under a Wayland session server. Allows writing
socket activated Wayland servers.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Sung-Jin Park <sj76.park@samsung.com>
Cc: Sangjin Lee <lsj119@samsung.com>
From irc:
<pq> it creates a wl_buffer object in a way that no client can ever
access the storage.
So, let's replace it with return NULL; and mark it with attribute
deprecated in the header.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
A few of the header files had function prototypes that were not
following project conventions, sometimes even in the same file.
Corrected these to follow as per wayland-os.h.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Sometimes the compositor wants to make sure a shm pool doesn't disappear
out from under it.
For example, in Enlightenment, rendering happens in a separate thread
while the main thread can still dispatch events. If a client is destroyed
during rendering, all its resources are cleaned up and its shm pools are
unmapped. This causes the rendering thread to segfault.
This patch adds a way for the compositor to increment the refcount of the
shm pool so it can't disappear, and decrement it when it's finished.
The ref/unref are asymmetrical (ref returns the pool) because it's
possible the buffer itself will be gone when you need to unref the pool.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
wayland-client.h and wayland-server.h include the protocol headers generated
at build time. This means that a libwayland user cannot generate and use
protocol code created from a wayland.xml newer than the installed libwayland,
because it is not possible to only include the API header.
Another use case is language bindings, which would generate their own protocol
code and which only need to use the library ABI, not the generated C code.
This commit adds wayland-client-core.h and wayland-server-core.h which do not
include the protocol headers or any deprecated code.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
