The protocol currently is in a state where we define that commits create
content updates and they are queued up until they are applied, and the
old view that commit applies the state or caches it in the parent state.
This commit moves the protocol completely to the new model which retains
the old behavior when no constraints are being used but allows for
constraints to be used to hold back a group of synchronized content
updates.
To convince yourself that this indeed retains the original behavior I
suggest to play around with a few examples and look at the resulting
graphs, as is done here:
https://gitlab.freedesktop.org/wayland/wayland/-/issues/457#note_2403135
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>
I think the docbook deserves an introduction to how color management is
designed in Wayland, aimed at people who are familiar with pixels but
new to the topic.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Previously each value was a list of extra sources. The next commit will add an
additional field to each test, so they need to be dicts themselves.
Signed-off-by: Matt Turner <mattst88@gmail.com>
This change mentions the case where WAYLAND_SOCKET is used, which helps
people avoid just testing 'getenv(WAYLAND_DISPLAY)' to see if a
Wayland compositor is available;
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Do not override realloc's input pointer before checking for errors,
otherwise it's not possible to keep old value, as intended.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
If cursor files require more than INT_MAX bytes, it is possible to
trigger out of boundary writes.
Since these sizes are most likely not desired anyway, gracefully
handle these situations like out of memory errors.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
If the full path could not be constructed, avoid calling opendir(NULL)
which, depending on library, might trigger undefined behavior.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
If an index.theme contains a theme name which gets close to INT_MAX,
then creation of full path can lead to a signed integer overflow,
which is undefined behavior.
Fix this by turning one of the values to size_t. Easy solution for a
probably never occurring issue.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
This protocol has been superseded. Replace this outdated reference
with a generic hint that protocol extensions may provide this
functionality.
Signed-off-by: Simon Ser <contact@emersion.fr>
It wasn't explicitly stated that wl_seat.capabilities should also
be sent on bind. Everyone did because it was obviously sensible.
This also clarifies that static seat name should be sent before
announcing capabilities so clients can associate these devices with the
right seat name.
Signed-off-by: David Edmundson <davidedmundson@kde.org>
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>
Sebastian pointed out that the existing text could be read as
wl_buffer.destroy not being allowed before the wl_buffer.release event
arrives, contrary to what the wl_surface.attach description says.
Clarify to be consistent with the latter.
This is a follow-up for
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/141 .
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
v2:
* Simplify clarification, don't talk about callbacks. (Julian Orth)
* Add reference to details in the description of wl_surface.attach.
(Daniel Stone)
v3:
* Tweak clarification again. (Sebastian Wick)
v4:
* Make clarification even less ambiguous. (Simon Ser, Julian Orth)
v5:
* Just refer to the description of wl_surface.attach instead of trying
to clarify anything here. (Sebastian Wick)
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
Add tests which verify that...
* wl_display_dispatch_timeout with a big enough timeout behaves the same
as wl_display_dispatch
* wl_display_dispatch_timeout will time out when there are no messages
to dispatch
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
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>
