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.
If an output with no mode and no valid pending resolution is attempted
enabled, it will trigger an assert in swapchain allocation instead of
failing on a rejected atomic commit or pre-commit test.
We can sometimes get such broken outputs if e.g., the underlying driver
failed to retrieve EDID, and so crashing on assert is suboptimal.
Reject zero-sized swapchains early and log the issue.
Exposing libinput_tablet_tool from libinput allows compositors
to set tool specific configuration options like pressure range
and eraser button behavior.
See 'libinput_tablet_tool_*()' functions which require a
'libinput_tablet_tool' handle:
https://wayland.freedesktop.org/libinput/doc/1.30.0/api/group__config.html
(libinput 1.30.0, latest at the time of writing).
We don't want to iterate the subtree for trivial update scenarios. We only
care when a scene is reparented or disabled in which both cases provides
us with explicit damage
We were sending an output frame event as soon as we were done
rendering. As a result, the output would render in a busy loop when
a client was using the capture output for frame pacing purposes.
Instead, use the request_frame hook introduced in the previous
commit to throttle output frame events.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/4036
schedule_frame is only called when the client has submitted damage
and a new frame should be rendered immediately. schedule_frame is
not called when the capture client is waiting for the next frame
but hasn't submitted damage.
Sources implementing a rendering loop based on the capture rate
need to know when a capture client is ready to accept a new frame.
Such sources want to trigger a redraw if and only if (1) they are
dirty (their contents have changed) and (2) the capture client is
ready to accept a new frame.
Replace schedule_frame with request_frame, triggered each time a
client sends a capture request. A flag indicates whether the capture
client has submitted damage.
