And the allowed state transitions.
There has been some confusion regarding which state transitions are
allowed. This change should clarify this.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
Currently WAYLAND_DEBUG text ignores events that have no listener.
It can be helpful to know when you're receiving unhandled events,
as you may have forgotten to add a listener, or adding a dispatch
may have magically seemed to fix code that doesn't appear to be
dispatching anything.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Multiple protocols use the term content update without a fill
definition. It makes sense to define it in the core protocol so that not
every other protocol has to define it.
This is supposed to retain the current semantics and only changes the
documentation while defining new terms.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Fixes the following warning:
src/wayland-client-core.h:125: warning: Found non-existing group 'wl_proxy' for the command '@ingroup', ignoring command
"\memberof" cannot be used here because it only works on functions.
The docs for "\memberof" say that "\relates" works in a similar way.
While at it, use a "\" command instead of a "@" command for
consistency with the rest of the file.
Signed-off-by: Simon Ser <contact@emersion.fr>
Add a new event and enum entry to small.xml with a deprecated-since
attribute to exercise the scanner code generation.
Signed-off-by: Simon Ser <contact@emersion.fr>
This marks a request, event or enum entry as deprecated since a
given version.
Note that it's not clear what it means if an entry is deprecated
at some version, and the enum is used from some completely different
interface than where it was defined. However, that's a more general
issue with enums, see:
https://gitlab.freedesktop.org/wayland/wayland/-/issues/435
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/wayland/wayland/-/issues/89
As of currently, when an xcursor theme depends on itself or another theme
that will eventually depend on it, `xcursor_load_theme` will recurse
infinitely while processing the inherits.
This change introduces a stack-allocated linked list of visited nodes
by name, and skips any already visited nodes in the inherit list.
Side effects:
* Since the linked list is stack-allocated, there is a potential for an
overflow if there is a very long list of dependencies. If this turns out
to be a legitimate concern, the linked list is trivial to convert to
being heap-allocated.
* There is an existing linked list (technically doubly linked list)
implementation in the wayland codebase. As of currently, the xcursor
codebase does not refer to it. Consequently, this change writes a
minimal single linked list implementation to utilize directly.
This changeset fixes#317.
Signed-off-by: Chloé Vulquin <toast@bunkerlabs.net>
Right now compositors need to manually check that enum values sent
by the client are valid. In particular:
- Check that the value sent by the client is not outside of the enum.
- Check that the version of the enum entry is consistent with the
object version.
Automatically generate validator functions to perform these tasks.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/104
The new text describes how
- Mutter
- Plasma
- Sway 1.8
- Jay
behave.
Sway 1.9 flipped the behavior of 90 degree and 270 degree
set_buffer_transform requests. [mpv] also changed the behavior of its
vo_wayland_dmabuf backend which makes it only work correctly on sway
1.9.
[mpv]: https://github.com/mpv-player/mpv/pull/12509
It seems that the previous text was open to interpretation or at least
caused some amount of confusion.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
Effective from Linux 6.3 onward, this creates the memfd without execute
permissions and prevents that setting from ever being changed. A
run-time fallback is made to not using MFD_NOEXEC_SEAL when a
libwayland-cursor compiled on Linux >= 6.3 is run on Linux < 6.3.
This is a defense-in-depth security measure and silences a respective
kernel warning; see: https://lwn.net/Articles/918106/
This implementation is adopted from dnkl's `foot` terminal emulator.
Signed-off-by: 6t8k <6t8k@noreply.codeberg.org>
Fixes the following warning:
tests/meson.build:91: WARNING: Project targets '>= 0.56.0' but uses feature introduced in '0.57.0': env arg in run_target.
Signed-off-by: Simon Ser <contact@emersion.fr>
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
This appears to be what at least wlroots-based compositors and kwin do
in practice. However, it's not abundantly clear from the protocol text
what the expected behavior here is. This patch fixes that.
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
This generates a header with only enum definitions. This is useful
to share enum headers between libraries and library users.
Signed-off-by: Simon Ser <contact@emersion.fr>
The symbols check only works for dynamic libraries.
When building statically, the test fails.
This is caused by the check filtering out non-dynamic symbols with nm.
This change skips the check when building only static libraries.
Signed-off-by: Jordan Williams <jordan@jwillikers.com>
If a wl_array has size zero, wl_array_for_each computes NULL + 0 to get
to the end pointer. This should be fine, and indeed it would be fine in
C++. But the C specification has a mistake here and it is actually
undefined behavior. See
https://davidben.net/2024/01/15/empty-slices.html
Clang's -fsanitize=undefined flags this. I ran into this in Chromium's
build with wayland-scanner on one of our XML files.
../../third_party/wayland/src/src/scanner.c:1853:2: runtime error: applying zero offset to null pointer
#0 0x55c979b8e02c in emit_code third_party/wayland/src/src/scanner.c:1853:2
#1 0x55c979b89323 in main third_party/wayland/src/src/scanner.c
#2 0x7f8dfdb8c6c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#3 0x7f8dfdb8c784 in __libc_start_main csu/../csu/libc-start.c:360:3
#4 0x55c979b70f39 in _start (...)
An empty XML file is sufficient to hit this case, so I've added it as a
test. To reproduce, undo the fix and include only the test, then build
with:
CC=clang CFLAGS="-fno-sanitize-recover=undefined" meson build/ -Db_sanitize=undefined -Db_lundef=false
ninja -C build test
Signed-off-by: David Benjamin <davidben@google.com>
This is less cryptic to read than letters, and allows the compiler
to check switch statements exhaustiveness.
Signed-off-by: Simon Ser <contact@emersion.fr>
There are situations in which a call into wl_client_destroy() can
result in a reentrant call into wl_client_destroy() - which
results in UAF / double free crashes.
For example, this can occur in the following scenario.
1. Server receives a message notifying it that a client has
disconnected (WL_EVENT_HANGUP [1])
2. This beings client destruction with a call to wl_client_destroy()
3. wl_client_destroy() kicks off callbacks as client-associated
resources are cleaned up and their destructors and destruction
signals are invoked.
4. These callbacks eventually lead to an explicit call to
wl_display_flush_clients() as the server attempts to flush
events to other connected clients.
5. Since the client has already begun destruction, when it is
reached in the iteration the flush fails wl_client_destroy()
is called again [2].
This patch guards against this reentrant condition by removing
the client from the display's client list when wl_client_destroy()
is first called. This prevents access / iteration over the client
after wl_client_destroy() is called.
In the example above, wl_display_flush_clients() will pass over
the client currently undergoing destruction and the reentrant
call is avoided.
[1] 8f499bf404/src/wayland-server.c (L342)
[2] 8f499bf404/src/wayland-server.c (L1512)
Signed-off-by: Thomas Lukaszewicz [thomaslukaszewicz@gmail.com](mailto:thomaslukaszewicz@gmail.com)
- wayland-egl-abi-check: try to use llvm-nm first instead of BSD nm (incompatible options)
- avoid forcing _POSIX_C_SOURCE=200809L (SOCK_CLOEXEC become available)
- epoll(7) is provided by a userspace wrapper around kqueue(2) as FreeBSD
- when using SO_PEERCRED, the struct to use is `struct sockpeercred` instead of `struct ucred` on OpenBSD
- provide a compatibility layer for count_open_fds() using sysctl(2) as FreeBSD
Signed-off-by: Sebastien Marie <semarie@online.fr>
The wl_output events should not be used anymore for guessing the
preferred scale and transform of a surface. We have explicit events
for that now.
Signed-off-by: Simon Ser <contact@emersion.fr>
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>
Currently it is possible to iterate over client-owned resources
during client destruction that have had their associated memory
released.
This can occur when client code calls wl_client_destroy(). The
following sequence illustrates how this may occur.
1. The server initiates destruction of the connected client via
call to wl_client_destroy().
2. Resource destroy listeners / destructors are invoked and
resource memory is freed one resource at a time [1].
3. If a listener / destructor for a resource results in a call
to wl_client_for_each_resource(), the iteration will proceed
over resources that have been previously freed in step 2,
resulting in UAFs / crashes.
The issue is that resources remain in the client's object map
even after they have had their memory freed, and are removed
from the map only after each individual resource has had its
memory released.
This patch corrects this by ensuring resource destruction first
invokes listeners / destructors and then removing them from the
client's object map before releasing the associated memory.
[1] https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-server.c?ref_type=heads#L928
Signed-off-by: Thomas Lukaszewicz thomaslukaszewicz@gmail.com
"is incompatible with the implementation in libwayland" is a common
source of confusion as evidenced by repeated discussions in IRC
channel.
Improve the wording by making clear that
- packing IDs is a protocol requirement
- there are implementations (including libwayland) that enforce it
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Allow setting a name for an event queue. The queue is used only for
printing additional debug information.
Debug output can now show the name of the event queue an event is
dispatched from, or the event queue of a proxy when a request is made.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Some code paths that lead to a client error and connection termination
have no associated logging, or insufficient logging. This makes it
difficult to understand what went wrong. This commit adds or supplements
logging for all these code paths.
Signed-off-by: Erik Chen <erikchen@chromium.org>
wl_connection_write() contained an exact copy of the logic in
wl_connection_queue(). Simplify things by just calling
wl_connection_queue() from wl_connection_write().
Signed-off-by: John Lindgren <john@jlindgren.net>
For libs/cflags this is done automatically, but not for manually accessed
variables. This matches what wayland-protocols does.
Signed-off-by: Andreas Cord-Landwehr <cordlandwehr@kde.org>
Allows clients to cleanly release wl_shm objects. Useful for clients
using multiple wl_registry objects (e.g. via libraries).
Signed-off-by: Simon Ser <contact@emersion.fr>
This was hardcoded to 1 regardless of the version passed to the
callback or the version of the parent resource.
Signed-off-by: Simon Ser <contact@emersion.fr>
Since the positivity of zero is debatable, and, in some cases scale was simply
underspecified, clarify the situation.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
