This avoids processing events which we're not interested in.
Specifically, this fixes a case where output_commit() could be
indirectly called from itself either from import_dmabuf() or while
waiting for a configure event when enabling the output.
The old approach of using a signal is fundamentally broken for a common
usecase: When the waiter is ready, it's common to immediately finish and
free any resources associated with it.
Because of the semantics of wl_signal_emit_mutable() this is UB.
wl_signal_emit_mutable() always excepts that the waiter hasn't been freed
until the signal has finished being emitted.
Instead of over engineering the solution, let's just add a callback required
by wlr_drm_syncobj_timeline_waiter_init(). In this callback, the implementation
is free to finish() or free() any resource it likes.
wl_buffer.release event delivery becomes undefined when using the
linux-drm-syncobj-v1 protocol, so we need to wait for buffer
release via a timeline point instead.
The protocol requires both wait and signal timelines to be set, so
we need to create one when the compositor only supplies a wait
timeline.
This commit fixes the following interaction:
1) The host compositor sends a configure sequence for an output.
2) Before handling it, the guest compositor disables and immediately
re-enables the output.
3) The guest compositor tries to ack the configure event from step 1
which isn't relevant anymore after unmapping and re-initialization.
Instead, ignore all configure events after unmapping until we're sure
the host compositor has processed the unmapping.
Also see
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/108.
- Reset all variables representing an initialized xdg_toplevel's state
on unmap.
- Send an initial commit only when an output is about to be enabled.
- If an output isn't configured yet, don't commit a buffer.
We can just assume CLOCK_MONOTONIC everywhere.
Simplifies the backend API, and fixes clock mismatches when multiple
backends are used together with different clocks.
When integrating wlroots with another toolkit, wlroots may receive
wl_pointer.enter events for surfaces not backed by a wlr_output.
Ignore such surfaces by tagging the ones we're aware of with
wl_proxy_set_tag().
since wayland doesn't provide a touch id in cancel events, track what
points are active so we can cancel all of them
timestamp is also not provided - use 0 because no one's paying attention
to that anyway
Closes#3000
Instead of destroying all seats, destroy a single one. We only need
to destroy all seats at one call-site (backend_destroy), but we'll
need to destroy a single seat elsewhere in the next commit.
We were firing the new_input signal on backend initialization,
before the compositor had the chance to add a listener for it.
Mimick what's done for wl_keyboard: if the backend hasn't been
started, delay wl_touch initialization.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3473
All the code logic related to the pointer has been moved to its own file.
The seat is responsible for the lifetime of its wlr_wl_pointer(s), and assigning
them to the relevant wlr_wl_output. The wlr_wl_pointer becomes a simple helper
to manager the wlr_pointer associated to the seat's wl_pointer and its lifetime.
This field's ownership is unclear: it's in wlr_input_device, but
it's not managed by the common code, it's up to each individual
backend to use it and clean it up.
Since this is a backend implementation detail, move it to the
backend-specific structs.
There's no guarantee that the parent Wayland compositor uses
CLOCK_MONOTONIC for reporting presentation timestamps, they could
be using e.g. CLOCK_MONOTONIC_RAW or another system-specific clock.
Forward the value via wlr_backend_impl.get_presentation_clock.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3254#note_1143061
Instead of passing a wlr_texture to the backend, directly pass a
wlr_buffer. Use get_cursor_size and get_cursor_formats to create
a wlr_buffer that can be used as a cursor.
We don't want to pass a wlr_texture because we want to remove as
many rendering bits from the backend as possible.
