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
This patch makes it so we bind to zwp_linux_dmabuf_v1 version 4 and
we use it to grab the main device. v4 sends supported formats via a
table so we need to handle this as well.
v4 allows wlroots to remove the requirement for Mesa's internal
wl_drm interface.
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 ensuring the renderer and allocator are initialized in each
backend, do it in wlr_backend_autocreate. This allows compositors to
create backends without any renderer/allocator if they side-step
wlr_backend_autocreate.
Since the wlr_backend_get_renderer and backend_get_allocator end up
calling wlr_renderer_autocreate and wlr_allocator_autocreate, it sounds
like a good idea to centralize all of the opimionated bits in one place.
Custom backends and renderers need to implement
wlr_backend_impl.get_buffer_caps and
wlr_renderer_impl.get_render_buffer_caps. They can't if enum
wlr_buffer_cap isn't made public.
When picking a format, the backend needs to know whether the
buffers allocated by the allocator will be DMA-BUFs or shared
memory. So far, the backend used the renderer's supported
buffer types to guess this information.
This is pretty fragile: renderers in general don't care about the
SHM cap (they only care about the DATA_PTR one). Additionally,
nothing stops a renderer from supporting both DMA-BUFs and shared
memory, but this would break the backend's guess.
Instead, use wlr_allocator.buffer_caps. This is more reliable since
the buffers created with the allocator are guaranteed to have these
caps.
This new functions cleans up the common backend state. While this
currently only emits the destroy signal, this will also clean up
the renderer and allocator in upcoming patches.
Split render/display setups have two separate devices: one display-only
with a primary node, and one render-only with a render node. However
in these cases the EGL implementation and the Wayland compositor will
advertise the display device instead of the render device [1]. The EGL
implementation will magically open the render device when the display
device is passed in.
So just pass the display device as if it were a render device. Maybe in
the future Mesa will advertise the render device instead and we'll be
able to remove this workaround.
[1]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4178
It turns out wl_event_source_check is not enough to guarantee that the
remote wl_display will be flushed after we queue requests. We need to
explicitly flush, just like we do in our X11 code.
References: https://gitlab.freedesktop.org/wayland/wayland/-/issues/187
This callback allowed compositors to customize the EGL config used by
the renderer. However with renderer v6 EGL configs aren't used anymore.
Instead, buffers are allocated via GBM and GL FBOs are rendered to. So
customizing the EGL config is a no-op.
The Wayland platform doesn't have visuals. By chance,
WL_SHM_FORMAT_ARGB8888 is zero, which means egl_get_config was ignoring
it and everything worked fine.
Alexander Orzechowski
Simon Ser
José Expósito
Simon Zeni
Ronan Pigott
Manuel Stoeckl
Mykola Orliuk