Use bool instead of int for boolean values, to make it more
explicit what the field contains. For instance "error" is not to
be confused with an error code.
This is all private API.
Signed-off-by: Simon Ser <contact@emersion.fr>
The offset in wl_surface.attach has been superseded by
wl_surface.offset. Refer to the new request instead of using the
deprecated one.
Signed-off-by: Simon Ser <contact@emersion.fr>
There are two ways to do pre-multiplication of the alpha channel into
the color channels: on optical values or on electrical values. While
pre-multiplication with optical values is arguably more correct, because
operations like blending or scaling require pre-multiplied, optical
color channels, wayland and compositors by default work with
pre-multiplied electrical values. This is most likely a convention that
Wayland took from Cairo.
This commit makes sure that the expectation of pre-multiplied electrical
values is properly documented.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
If wl_event_loop_dispatch() fails, we could enter an infinite loop,
repeatedly calling a failing wl_event_loop_dispatch() forever.
Signed-off-by: Simon Ser <contact@emersion.fr>
the 'has_timers' flag can be returned directly without having to track all the ready events
when a timer is found ready.
Signed-off-by: Yang Wang <KevinYang.Wang@amd.com>
Because this benchmark performed wl_fixed_to_double conversions
on a long sequence of consecutive integers, the compiler could
optimize away the addition performed in wl_fixed_to_double, merging
it with the loop iteration code. This made tests/fixed-benchmark.c
significantly underestimate the actual cost of the current
wl_fixed_to_double implementation.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
This fixes an issue where it was not possible to start Gamescope under GDB on some setups.
https://github.com/ValveSoftware/gamescope/issues/743
Any signals would cause epoll_wait to return -1 and set errno to EINTR.
This also handles the EAGAIN case like the other polling loops in libwayland.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
The compositor must not send any key events while a surface is not focused,
but in order to allow for common actions like ctrl+scroll for zooming to work
with unfocused surfaces it may do so with modifiers.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
As pointed out in [1], re-using a wl_data_source for multiple start_drag or
set_selection requests has bad consequences, because this object has events
that allo tracking the state of a selection/drag-and-drop operation. Tracking
two operations at the same time isn't possible with this interface.
[1]: https://lists.freedesktop.org/archives/wayland-devel/2019-January/039936.html
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Daniel Stone <daniels@collabora.com>
This will let command-line Git tools re-map my name and e-mail address properly.
I'm using my personal e-mail address and not my Collabora address because I'm
not actively contributing to Wayland anymore and this is mostly for letting
people find me should they dig me up in the project history.
Signed-off-by: Faith Ekstrand <faith@gfxstrand.net>
If the default queue is being destroyed, the client is disconnecting
from the wl_display, so there is no possibility of subsequent events
being queued to the destroyed default queue, which is what this warning
is about.
Note that interacting with (e.g., destroying) a wl_proxy after its
wl_display is destroyed is a certain memory error, and this warning will
indirectly warn about this issue. However, this memory error should be
detected and warned about through a more deliberate mechanism.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Detect when we are trying to add an event to a destroyed queue,
and abort instead of causing a use-after-free memory error.
This situation can occur when an wl_event_queue is destroyed before
its attached wl_proxy objects.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Add the display_destroy_expect_signal() function to check that test
clients exit due to a particular signal. This is useful for checking
that clients fail in an expected way.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Log a warning if the queue is destroyed while proxies are still
attached, to help developers debug and fix potential memory errors.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Capture the test client log to a temporary fd, so that is accessible by both
the test server process and the test client process.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Maintain a list of all wl_proxy objects that are attached to a
wl_event_queue. We will use this information in upcoming commits to warn
about improper object destruction order that can lead to memory errors.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
With wl_shm_buffer_ref_pool(), it's possible for a wl_shm_pool
to outlive its wl_resource. We need to be careful not to access
wl_shm_pool.resource if it's been destroyed.
Reset resource to NULL in the resource destroy handler, and add
NULL checks.
Signed-off-by: Simon Ser <contact@emersion.fr>
Input region is ignored for cursors, DnD icons. Current wording
implies that this state is temporary, but surfaces never lose the
role once assigned, so reword to make it clearer.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Most compositors send the wl_data_offer.source_actions event before the
wl_data_device.enter event, i.e. after creation of the data offer. This
contradicts to the wayland spec.
On the other hand, it's reasonable to send all the information useful to
the client before the enter event, rather than send mime types before the
enter event and source actions (that don't depend on drop target) after
the enter event.
On the client side, toolkits such as Qt and GTK already expect to see the
source actions before receiving the enter event.
Given all of that, this change adjusts the spec to match the behavior
observed in the compositors in the wild.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Attaching a buffer with interface version 5 requires clients to pass
zero to x and y but it still affects the pending surface state.
Attaching a buffer after a request to offset therefore sets the pending
x and y to zero. The intent of version 5 was to allow exactly this
sequence of requests to work so let's just make sure the protocol
actually spells it out.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
This event adds the physical direction of the axis motion, relative to the
axis event we get. Right now, when natural scrolling is enabled things like
virtual volume sliders move the wrong way round.
By adding the axis motion direction, we can have toolkits swap the scroll
direction for applicable widgets, getting the right behavior on all widgets.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
The website is most useful for docs. Build instructions have been
mostly dropped from it: they're better described in downstream
projects' READMEs.
Signed-off-by: Simon Ser <contact@emersion.fr>
Same as the new wl_surface.preferred_buffer_scale event but for
transform.
No version bump needed since the previous commit did that.
Signed-off-by: Simon Ser <contact@emersion.fr>
Right now, clients need to bind to wl_output globals, listen to wl_output.scale,
listen to wl_surface.enter/leave, pick the highest scale factor.
This is an issue because it breaks Wayland's "policy, not mechanism" motto.
Clients take the decision of which scale to use depending on the outputs they're
on, compositors have no say in this (apart from faking output events, which
isn't great).
This commit introduces a new wl_surface.preferred_buffer_scale event to allow
compositors to directly indicate the preferred scale factor for each surface.
This unlocks features which require dynamically changing the scale such as:
- Accessibility features such as screen magnifier
- In a VR environment, render surfaces close to the eye at a higher scale
- HiDPI screenshots on LoDPI screens
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/271
display->id is initialized to 1, making 0 a convenient value to
indicate an invalid global name. Make sure to not return a zero
global name on overflow. Moreover, if we wrap around, we might
cycle back to a global name which is already in-use.
Signed-off-by: Simon Ser <contact@emersion.fr>
Role assigned to wl_surface cannot be removed.
Delete contradicting text from wl_subsurface::destroy documentation.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
According to clang, qsort cannot be passed a null pointer, even if the size is
specified to be zero. The scanner can hit this while trying to sort forward
declarations if it happens to be building a protocol file that doesn't require
any, either in the header or the source.
Signed-off-by: Fergus Dall <sidereal@google.com>
This commit adds wl_surface.defunct_role_object error, which has
semantics similar to xdg_wm_base.defunct_surfaces error, and is sent
when a client destroys a surface while the corresponding role object
still exists.
Signed-off-by: Kirill Primak <vyivel@eclair.cafe>
This statement assumes that a wl_surface can be destroyed before the
corresponding wl_subsurface, which is not true, as wl_surface
description explicitly states that the role object must be destroyed
before the wl_surface itself.
Signed-off-by: Kirill Primak <vyivel@eclair.cafe>
Make sure that the client destroy handler runs strictly before the
resource destroy handler, which runs strictly before the client
late-destroy handler.
Signed-off-by: Daniel Stone <daniels@collabora.com>
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
