Currently we flush damage for the "primary plane" every repaint, but this
is folly.
The drm backend may skip rendering entirely if using an all-planes
composition. This could leave the renderer plane in a messy state if a
surface on an overlay plane disappears.
Instead, let the backends flush the primary plane damage when they know
they need to render.
Fixes#864
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Insert the backend into the weston_compositor::backend_list instead
of setting weston_compositor::backend. The compositor uses this to
determine whether the backend is capable of being loaded simultaneously
with other backends.
To stay backwards compatible, the PipeWire backend can be loaded as
primary backend. It also supports being loaded as secondary backend.
Co-authored-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Extract the finish frame timestamp code and the call to
weston_output_finish_frame() into a new helper function
weston_output_finish_frame_from_timer() that can be reused
by the other timer driven backends sharing the same logic.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Extract pipewire_output_arm_timer() into libweston so it can be reused
by the other timer driven backends that use the same delay logic.
Call the shared function weston_output_arm_frame_timer().
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Round up the ms delay to make sure that the finish_frame_timer always
expires after the next frame_time. That way, finish_frame_handler()
never passes a timestamp in the future to weston_output_finish_frame().
Setting frame_time into the future risks hitting an assert in
weston_output_finish_frame(), when it is called from start_repaint_loop
within the frame interval.
Use CLIP() to simplify limiting the ms delay to a reasonable range.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Let backends declare the presentation clocks they can use with a
new bitfield weston_backend::supported_presentation_clocks and set
presentation clock after loading the backend in the compositor.
Make weston_compositor_set_presentation_clock() internal and replace
weston_compositor_set_presentation_clock_software() with an exported
weston_compositor_backends_loaded(), which is called by the compositor
after the backend is loaded.
In the future, this can be extended to determine the subset of clocks
supported by all backends.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Right now every backend clears output damage from the primary plane when
it repaints. Instead of having this same operation spread across all
the backends, just do it in the core instead.
In the future, we want to remove damage tracking from the primary plane
entirely, and this is a small step in that direction.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
If we want to support multiple backends, the compositor must take care
to call this once, at the appropriate moment, so stop letting the
backends handle compositor shutdown themselves.
Move the weston_compositor_shutdown() calls from the backend::destroy
callbacks into weston_compositor_destroy() and the calls in the backend
creation error paths into weston_compositor_load_backend().
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
While the GL renderer is not able to directly render into the PipeWire buffers,
it is possible to read the rendered frame from the fbo into the PipeWire buffer.
Use the automatic download to add support for the GL renderer to the PipeWire
backend.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Instead of always initializing the Pixman renderer, make the initialization
dependent on the selected renderer. This makes it easier to add other renderers.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Make it easier to understand where ptr points to by using local variables for
the spa_buffer and spa_data.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Extract the pixman renderbuffer configuration from the add_buffer function into
a helper function to simplify the addition of the GL renderer.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Use helper function for setting up the pixman renderer to simplify the addition
of the GL renderer.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Consolidates the 'Using GL/Pixman renderer' message emitted by the
PipeWire, RDP, VNC, and X11 backends by moving the weston_log() into
weston_compositor_init_renderer(). Only print the message after
initializing the renderer has succeeded.
This effectively adds the message to the DRM, headless, and Wayland
backends.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
In Pipewire and Gstreamer terminology Weston is a "live" source (as we
do not explicitly set PW_KEY_STREAM_IS_LIVE to false).
Such sources, be it compositors, cameras or microphones, usually set
the current system time as timestamps on buffers in order to make life
easier for consumers. Thus let's do so as well.
This notably helps when recording using `gstpipewiresrc` with the
`keepalive-time` property set.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
As of PipeWire version 0.3.69, the gstpipewiresrc element uses the
existence of a modifier as a trigger to select dmabuf memory, failing
caps negotiation as we don't send DMA buffers yet.
Remove the linear modifier for now, to be added back when we add dmabuf
support to the PipeWire backend. This allows testing the PipeWire
backend with current GStreamer + PipeWire.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Pass the backend instead of the compositor to the PipeWire output API
create_head() method and increment the API version.
That way the backend will not have to find the backend pointer from the
compositor. This is trivial now, but in the multi-backend case would
entail iterating over all backends to find the correct one.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a separate PipeWire backend based on the PipeWire plugin. The backend
requires PipeWire 0.3.x.
The PipeWire backend can be used as a standalone-backend backend for streaming
and composing Wayland clients to PipeWire.
The backend supports the on-demand creation of heads via the
weston_pipewire_output_api_v1. It also supports per-output pixel format
configuration via a gbm-format option.
Multiple PipeWire outputs can be created by setting the num-outputs option in
the [pipewire] section.
Co-authored-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
