This destroys the xdg popups associated with a layer surface when the
layer surface is unmapped. It does not make sense to keep the popups
open when unmapped.
libinput_event_touch_get_slot always returns -1 for single touch devices. Using
libinput_event_touch_get_seat_slot instead ensures that they are assigned actual
slot ids.
Also, this is what Weston does, so this change yields a more consistent
behaviour between different compositors.
From the xdg-shell specification:
If the parent is unmapped then its children are managed as
though the parent of the now-unmapped parent has become the
parent of this surface. If no parent exists for the now-unmapped
parent then the children are managed as though they have no
parent surface.
It's added to manager->input_methods list in manager_get_input_method, but
wasn't removed anywhere, leading to possible use-after-free in
wlr_input_method_manager_v2_destroy.
Instead of waiting for the next pageflip, destroy the output immediately
since we can now handle flips for outputs which no longer exist.
Also demote the missing crtc on flip to debug.
Fixes#1739
This adds support for xdg-output-unstable-v1 version 3, added in [1].
The xdg_output.done event is now deprecated and is replaced with
wl_output.done.
[1]: 962dd53537
This commit makes more output properties (mode, enabled, scale and transform)
atomic. This means that they are double-buffered and only applied on commit.
Compositors now need to call wlr_output_commit after setting any of those
properties.
Internally, backends still apply properties sequentially. The behaviour should
be exactly the same as before. Future commits will update some backends to take
advantage of the atomic interface. Some backends are non-atomic by design, e.g.
the X11 backend or the legacy DRM backend.
Updates: https://github.com/swaywm/wlroots/issues/1640
This prevents screencopy applications from hanging because a failed
event never got sent when the output was disconnected or disabled after
the call to buffer().
Disconnecting or disabling an output between capture_output() and
ready() could cause either a NULL dereference or an incorrect
attach_render_locks count.
The documentation for wayland-server.h says:
> Use of this header file is discouraged. Prefer including
> wayland-server-core.h instead, which does not include the server protocol
> header and as such only defines the library PI, excluding the deprecated API
> below.
Replacing wayland-server.h with wayland-server-core.h allows us to drop the
WL_HIDE_DEPRECATED declaration.
AFAIK this was always set to zero. Instead, compute wl_output mode flags on the
fly.
Technically this is a breaking change, but I don't think anybody uses this
field.
This commit matches sway's 2dc4978d8af326c310057ca8fd22a4c7f5d09335.
To help ensure a reproducible build (when debug info is disabled),
the meson build script now uses the -fmacro-prefix-map command line
argument supported by GCC to strip the build-path dependent bytes
of each __FILE__ string used by wlr_log and related functions.
A rather ugly algorithm is used to compute the relative path between
the build and source folders, because meson has no specific function
for this.
When the compiler does not support -fmacro-prefix-map, fall back
to shifting the start of each __FILE__ string by the length of the
relative path to the source directory.
When the surface is destroyed clear it's reference but wait for the up
event to destroy the touch point via wlr_seat_touch_notify_up().
If the surface is destroyed before the up event we end up with
incomplete sequences sent to the client like
[915821.276] wl_touch@3.down(146, 2475027, wl_surface@38, 0, 236.000000, 515.000000)
[915821.608] wl_touch@3.frame()
[915821.637] wl_touch@3.motion(2475027, 0, 236.000000, 515.000000)
[915821.779] wl_touch@3.frame()
so there's never an up event. While it should be something like
[2461229.051] wl_touch@3.down(81, 3236959, wl_surface@34, 0, 218.000000, 478.000000)
[2461229.435] wl_touch@3.frame()
[2461229.484] wl_touch@3.motion(3236959, 0, 218.000000, 478.000000)
[2461229.636] wl_touch@3.frame()
[2461277.520] wl_touch@3.up(82, 3237007, 0)
[2461277.681] wl_touch@3.frame()
this confuses toolkits intepreting the next down event incorrectly. So
don't destroy the touch point too early.
