This changes the behavior of wlr_linux_drm_syncobj_surface_v1 to
automatically signal release of previous commits as they are replaced.
Users must call wlr_linux_drm_syncobj_v1_state_add_release_point or
wlr_linux_drm_syncobj_v1_state_signal_release_with_buffer to delay the
signal as appropriate.
(cherry picked from commit bfd6e619fc)
I want to use the zwp_virtual_keyboard_v1 object in a custom river
protocol and need to be able to obtain the corresponding wlroots struct.
(cherry picked from commit ec746d3e3e)
This guards against a crash where the server implements
wlr_ext_image_capture_source_v1_interface without setting .get_pointer_cursor().
In general, we should install a NULL check here because this is a crash
waiting to happen. Now, instead of crashing, the resource will be created and
the copy capture session will be stopped.
(cherry picked from commit 1fc928d528)
The outputs loop in handle_scene_buffer_outputs_update may remove entries
from the list while iterating, so use wl_list_for_each_safe instead of
wl_list_for_each.
Fixes: 39e918edc8 ("scene: avoid redundant wl_surface.enter/leave events")
(cherry picked from commit 3cb2cf9425)
Currently we send wl_surface.enter/leave when a surface is hidden
and shown again on the same output. In practice, this happens very
often since compositors like river and sway enable and disable
the scene nodes of surfaces as part of their atomic transaction
strategy involving rendering saved buffers while waiting for
clients to submit new buffers of the desired size.
The new strategy documented in the new comments avoids sending
redundant events in this case.
(cherry picked from commit 39e918edc8)
The X11 backend subscribes to StructureNotify events, so when
output_destroy() calls xcb_destroy_window() the server sends a
DestroyNotify back. This is expected and harmless but was logged
as an unhandled event. Silence it the same way MAP_NOTIFY and
UNMAP_NOTIFY are already silenced.
(cherry picked from commit 3c8d199ec1)
wlr_box_intersection only operates on integers, so we shouldn't use
fmin/fmax. Do the usual and add a local integer min/max helper.
(cherry picked from commit 285cee5f3a)
Without observing the enable event, clients receive no pixel formats and
buffer dimensions are reported as 0 after an output has been re-enabled.
(cherry picked from commit 3336d28813)
When pipe() fails in xwm_selection_send_data(), the function
returns without cleaning up the allocated transfer structure
and initialized wl_array. This causes a memory leak.
Add wl_array_release() and free() to clean up resources when
pipe() fails.
Signed-off-by: Wang Yu <wangyu@uniontech.com>
The v5 layer shell interface allows the client to specify which edge the
exclusive zone will apply to, instead of deducing it from the anchor
points. Add support for this to the layer shell scene helper.
When we're reading from a DMA-BUF texture using implicit sync, we
need to (1) wait for any writer to be done and (2) prevent any
writers from mutating the texture while we're still reading. We
were doing (1) but not (2).
Fix this by calling dmabuf_import_sync_file() with DMA_BUF_SYNC_READ
for all DMA-BUF textures we've used in the render pass.
We'll need to grab textures from there in the next commit.
Also rename it to better reflect what it does: synchronize release
fences after a render pass has been submitted.
When libinput introduces new enum entries, we'd abort or send bogus
events to the compositor. Instead, log a message and ignore the
event.
Keep all enums without a default case so that the compiler warns
when we're missing a case.
Ensure mime_types and mime_types_atoms remain in sync when
wl_array_add() fails. Roll back the partially added entry and
free the allocated mime type to avoid leaks and inconsistent
state.
wl_event_source_fd_update() goes through another event loop cycle, which
delays writes. This extra cycle was introduced in 6ada67da9b
("xwayland/xwm: implement somewhat asynchronous request flushing").
Try flushing the X11 WM FD immediately if we can.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/4044
If the wlr_keyboard_group_remove_keyboard function is expanded, the code
is equivalent to:
```
wl_list_for_each_safe(device, tmp_device, &group->devices, link) {
struct wlr_keyboard_group *_group = group;
struct wlr_keyboard *_keyboard = device->keyboard;
struct keyboard_group_device *_device, *_tmp;
wl_list_for_each_safe(_device, _tmp, &_group->devices, link) {
if (_device->keyboard == _keyboard) {
remove_keyboard_group_device(_device);
continue;
}
}
}
```
It's just running one more loop meaninglessly.
