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.
wlr_scene_output_needs_frame checks wlr_output.needs_frame and
wlr_scene_output.gamma_lut_changed, neither of which incur damage. The
needs_frame flag is often set by e.g., cursor movement.
For the purpose of a capture frame we are only interested in frames with
damage. Continue without damage causes session_handle_source_frame to
silently skip copying the frame, which causes the session to get stuck:
no ready or failed event is emitted, and frame_pending is still set so
no further output frame events will occur.
Only render in case there is damage, but send frame callbacks
regardless.
