On platforms without F_DUPFD_CLOEXEC, MSG_CMSG_CLOEXEC, or SOCK_CLOEXEC, we
should skip past their usage and just use the fcntl() fallback.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This adds an alternative implementation of wl_os_socket_peercred() using
getpeereid(3) and LOCAL_PEERPID, similar to changes I recently made to
xorg-server.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Previously, wayland-scanner would only emit one NULL entry in the
wl_message.types array for every argument, even though requests with
new_id arguments without an interface type additionally take a string
and a uint argument.
Signed-off-by: Hannes Schulze <contact@haschu.me>
fail() already calls exit(), so the extra exit() is never reached.
Remove it to avoid dead code.
Signed-off-by: YaoBing Xiao <xiaoyaobing@uniontech.com>
for_each_helper caches the entries->data pointer and array size before
iterating. If a compositor calls wl_client_for_each_resource() and the
provided callback triggers the creation of a new client object, the
underlying wl_array may be reallocated via realloc().
When this happens, the cached start pointer becomes dangling. Subsequent
iterations will read from the freed memory block, causing already-destroyed
resources to be destroyed a second time (e.g., leading to a double-free
crash in wl_list_remove()).
Fix this by dynamically re-fetching entries->data and entries->size on
every loop iteration, ensuring the iterator always accesses the valid
live array.
Signed-off-by: YaNing Lu <luyaning@uniontech.com>
Since the globals track the registries that received global
announcements, we can use that instead of going through all present
registries and duplicate some filtering logic.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
The wl_global_remove() function was introduce to help mitigate clients
getting unintentionally disconnected if a global is added and removed in
a short burst.
The intended usage was:
- the compositor calls wl_global_remove()
- after a certain period of time, the compositor calls
wl_global_destroy()
Unfortunately, it did not fully fix the issue due to the way monotonic
clock works on Linux. Specifically, it can tick even during sleep.
This change adds a slightly better way to handle global removal. With
the proposed changes, the clients need to signal to the compositor that
they won't bind the global anymore.
After all clients have acknowledged a wl_registry.global_remove, the
compositor can finally destroy the global.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
- Consistently use PRIu32 for global names (uint32_t)
- Use expected/got instead of have/wanted (which were used differently anyway)
Signed-off-by: Kirill Primak <vyivel@eclair.cafe>
Otherwise, a client iterate over a range of names binding with deliberately
incorrect interfaces and receive error messages with expected interfaces
regardless of global visibility.
Signed-off-by: Kirill Primak <vyivel@eclair.cafe>
struct wl_array may be constructed by users manually from a
foreign data pointer:
uint32_t states[] = {1, 2, 3};
struct wl_array arr = {
.data = states,
.size = sizeof(states) / sizeof(states[0]),
};
This is useful to avoid the need to allocate when sending Wayland
messages.
Users need to be careful not to use wl_array_add() on such arrays:
the function will misbehave by leaving garbage at the start of the
new buffer when reallocating.
Add an assert to guard against wl_array_add() calls in this
situation, to have a clear crash instead of undefined behavior.
Signed-off-by: Simon Ser <contact@emersion.fr>
Before, it worked if the client did set a queue on the proxy before any event was received.
Now we have the "warning: queue xxx destroyed while proxies still attached", then a crash if one of
the proxies is used to create a proxy.
Fixes: 674145dc3f ("client: Track the proxies attached to a queue")
Fixes: 0ba650202e ("client: Warn when a queue is destroyed with attached proxies")
Signed-off-by: Loïc Yhuel <loic.yhuel@softathome.com>
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>
This version will be required in the next commit.
Bumps the CI image to get the required version from the debian package
instead of from pip.
Removes the bindir builtin directory from pkgconfig.generate() which is
deprecated since 0.62.0. It will be automatically included when
referenced.
Use `meson setup` everywhere instead of relying on deprecated automatic
detection of the setup command.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
As well as wl_display_dispatch_queue_pending_single.
The motivation is writing libwayland bindings for a dynamic language
with exceptions/non-local returns. Since it is invalid for a
wl_dispatcher_func_t callback provided to libwayland to not return,
there is no way to prevent dispatching of further events in the case of
an exception in the dynamic language event handler.
Furthermore, since creating/destroying Wayland objects in an event
handler affects the dispatching of subsequent events by libwayland,
it is not possible to collect Wayland events in a queue outside
libwayland and dispatch them one-by-one after
wl_display_dispatch_pending() returns.
Adding libwayland API to dispatch at most one pending event solves this
problem cleanly. The bindings can have libwayland dispatch a single
event, wait for wl_display_dispatch_pending_single() to return, run the
dynamic language event handler (which may longjmp away), and continue
the loop for as long as there are more events to dispatch.
References: https://codeberg.org/ifreund/janet-wayland
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
If WAYLAND_DEBUG contains the token "thread_id", and gettid() is
available, then include the current thread ID in the output from
wl_closure_print.
If multiple threads are sending requests, then those requests can get
interleaved. That's usually fine, but for wl_surface requests and
commits, that can cause problems ranging from incorrect behavior to
protocol errors.
Being able to see which requests are sent by different threads would
make such problems much easier to diagnose.
Signed-off-by: Kyle Brenneman <kbrenneman@nvidia.com>
Add a new function, wl_check_env_token, to scan for a token in a
comma-separated string.
Change wl_display_create in wayland-server.c and
wl_display_connect_to_fd in wayland-client.c to use that instead of a
simple substring search.
This means that WAYLAND_DEBUG will accept a value like "client,server"
but not "clientserver". But, this will make it easier to add other
tokens without worrying about overlap between them.
Signed-off-by: Kyle Brenneman <kbrenneman@nvidia.com>
If the length of a message exceeds the maximum length of the buffer, the
buffer size will reach its maximum value and stay there forever, with no
message ever being successfully processed. Since libwayland uses
level-triggered epoll, this will cause the compositor to loop forever
and consume CPU time. In libwayland 1.22 and below, there was an
explicit check that caused messages exceeding 4096 bytes to result in an
EOVERFLOW error, preventing the loop. However, this check was removed
between d074d52902 ("connection: Dynamically resize connection buffers").
To prevent this problem, always limit the size of messages to 4096 bytes.
Since the default and minimum buffer size is 4096 bytes, this ensures
that a single message will always fit in the buffer. It would be
possible to allow larger messages if the buffer size was larger, but the
maximum size of a message should not depend on the buffer size chosen by
the compositor.
Rejecting messages that exceed 4092 bytes seems to have the advantage of
reserving 4 bits, not 3, in the size field for future use. However,
message sizes in the range [0x0, 0x7] are invalid, so one can obtain a
fourth bit by negating the meaning of bit 12 if bits 0 through 11
(inclusive) are 0. Allowing 4096-byte messages provides the far more
important advantage that regressions compared to 1.22 are impossible
and regressions compared to 1.23 are extremely unlikely. The only case
where a regression is possible is:
- The receiving side is using libwayland 1.23.
- The sending side is either using libwayland 1.23 or is not using
libwayland.
- The sender sends a message exceeding 4096 bytes.
- If the sender of the large message is the client, the server has
increased the buffer size from the default value.
This combination is considered extremely unlikely, as libwayland 1.22
and below would disconnect upon receiving such a large message.
4096-byte messages, however, have always worked, so there was no reason
to avoid sending them.
Fixes: d074d52902 ("connection: Dynamically resize connection buffers").
Fixes: #494
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
The paragraph later says that accessing different buffers is
allowed. The function checks whether the same pool is accessed.
Signed-off-by: Simon Ser <contact@emersion.fr>
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>
If the pool refcount reaches zero, it is freed, so accessing its members
is UB which ASan would catch.
Also simplify check for negative refcounts.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
This seems to have been the case since 2013.
This is useful for wrappers that need two pointers to identify proxies.
One pointer (stored in the user data) pointing to a singleton object to
identify that the proxy has a known structure. And one pointer (stored
in the dispatcher data) pointing to per-proxy data.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
Generated XXX_is_valid() functions for enums are guarded behind the
same #define as the enum itself. This worked fine until recently,
but since fbd7460737 ("scanner: add new enum-header mode") we're
also generating enum-only headers.
When including the enum-only header first, and then the server
header, the validator functions are missing.
Define a separate guard to fix this.
Signed-off-by: Simon Ser <contact@emersion.fr>
The `timespec` struct is defined in `time.h` header but only if
`_POSIX_C_SOURCE` is set or when using the C11 standard.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Now that wl_fixed_from_double() calls round() from a function declared
in a header, our users need to explicitly pick that dependency up in
order to avoid build errors.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Closes: wayland/weston#991
For dispatching messages on a queue with a timeout.
This slightly changes the samantics of wl_display_dispatch. Previously
it was possible for it to return even though there wasn't a single
dispatched event. The function correctly returned 0 in this case but it
is now used to indicate a timeout.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
