The fbo naming inherited from gl-renderer is confusing, and now it
is used in many places.
Rename the two options for output creation to surface and surfaceless
to hopefully make them more meaningful.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
If there's no running connection, we can't capture, so just burn down any
waiting tasks so we don't assert later.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
set_dpms() is used for sleep/wakeup. output_repaint_timer_handler() resets the
repaint_status if called while Weston is sleeping. If the timer is still active,
it will trigger a call to weston_output_finish_frame() which then triggers an
assertion, because the repaint_status is not REPAINT_AWAITING_COMPLETION.
Stop the timer and reset the repaint_status in this case to avoid this.
Schedule a repaint for WESTON_DPMS_ON to ensure that the current state is
rendered.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Add the Vulkan renderer in the pipewire backend renderer switches.
For now this goes over the pipewire memfd path.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Although backends can create renderbuffers of any size, they always
request the output's current mode size (including decorations).
Letting backends ask for a different size than the output has a few
read-back related design issues like for instance weston_renderer's
read_pixels() API users, currently assuming the output size and
without knowledge of renderbuffers, can retrieve cropped images if a
backend asks for a smaller size. Same issue for the output capture
subsystem.
This commit proposes to fix these issues by simply, albeit perhaps
radically, removing the width and height parameters from
create_renderbuffer(), enforcing the current mode's size of the
associated output.
The VNC and PipeWire backends now also access the output size via the
current mode, not through the width and height variables. This has the
benefit of unifying the backends, as well as the renderers, in their
use of output sizes.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
The Pixman renderer creates renderbuffers with the create_image() and
create_image_from_ptr() functions. The recent addition of the GL
renderer's create_fbo() function, which is pretty similar to the
Pixman ones, brings the opportunity to unify Pixman and GL renderers.
This commit proposes a common renderer function create_renderbuffer()
to create a renderbuffer of the specified format with an optional user
provided destination buffer.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
It's currently assumed by backends that renderers discard
renderbuffers on resize. This commit introduces a new
weston_renderbuffer_discarded_func callback that must be passed at
renderbuffer creation in order to be notified of discarded events from
the renderer. This discarded event could potentially be reused later
by renderers on other occasions without having to change backends once
they get proper support for that.
On output resize, once a discarded event handler fails (returns false)
on a renderbuffer, all the remaining renderbuffers in the output list
go stale and weston_renderer_resize_output() ultimately returns false
for backends to be notified of the failure.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Renderbuffers currently have a libweston-internal base data structure
with a ref-counting system to handle their lifetime. The problem is
that renderers keep a ref to all renderbuffers in a list per output
(to deal with damages) and that it prevents backends from releasing
renderbuffer resources when not needed anymore. Renderbuffers are then
only released (last ref removed) when the output is destroyed or
resized. dma-buf renderbuffers even expose a dedicated function
remove_renderbuffer_dmabuf() to explictly request the release of their
resources.
This commit proposes to get rid of the ref-counting system by exposing
a single entry point to explicitly destroy all types of renderbuffers
from the renderer.
Instead of removing a renderbuffer from its output list and dropping
its ref when the output is resized, this commit also introduces the
concept of stale renderbuffers which consists in releasing the
resources of a renderbuffer when it's discarded by the renderer while
keeping it in the output list, with a stale state, until it's
explicitly destroyed.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This is problematic as we don't have namespacing for these and some of
the macros can interfere with other defines.
This reverts commit 8634c7e349.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As weston_windowed_output_get_api needs ARRAY_LENGTH() move helpers to a
libweston/ so other users can re-use that instead of re-defining these
all over. Easier for other front-ends to make use of them.
With this change windowed-output-api.h also includes the helpers header.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Since c4eb15d453 we keep a copy of
native mode parameters, however we forgot to initialize the
native mode parameters in some situations, which breaks the
output mirroring code when it sees uninitialized data.
Fixes c4eb15d453Fixes#949
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
If the PipeWire-backend renders to a DmaBuf, try to use a fence to synchronize
the submit of the next PipeWire buffer to the completion of the current render
process.
This ensures that the GPU rendering is finished before the buffer is passed to
PipeWire.
If fences are not available, the buffer is submitted without explicit
synchronization as before.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The GL renderer allows the PipeWire backend to allocate DMABUFs that can be used
as renderbuffers and passed to PipeWire. This allows to avoid a copy of the
rendered output when using PipeWire.
PipeWire negotiates DmaBuf buffers using the SPA_FORMAT_VIDEO_modifier property.
Currently, the PipeWire-backend only announces and handles
DRM_FORMAT_MOD_LINEAR, which allows to share DmaBufs with consumers that have
modifier support for linear buffers. Consumers which could consume DmaBufs but
don't support modifiers (DRM_FORMAT_MOD_INVALID) are not supported. Moreover,
consumers that would benefit from other formats with modifiers, for example
tiled or compressed, aren't not supported, too.
Modifier negotiation can be added by extending the list of announced modifiers
and selecting and checking the proposed modifiers in param_changed.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Instead of letting PipeWire allocate the buffers, allocate them in the PipeWire
backend. This allows the PipeWire backend to define the type of the allocated
buffers, which will ultimately allow to allocate buffers that can be rendered
to.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Add a helper function for building the pod for the format.
This simplifies the creation of the EnumFormat params and to provide multiple
EnumFormats. Furthermore, it allows to optionally set add a Modifier to enable
DmaBuf negotiation.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The PipeWire backend is only able to render into renderbuffers and passing NULL
to the renderer is not valid. Don't try to use the renderbuffer if a buffer
without renderbuffer is dequeued from PipeWire.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
With commit a1f8c49d5b 'compositor: repaint backends separately'
we will be repainting outputs independently so there's no need to keep
this band-aid on. Further more, the comment was most likely wrong.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Failure to do so, might cause a crash if the output repaint happens
before the pipewire pipeline started -- calling pixman_region32_fini on
a uninitialized region.
Fixes 2abe4efcf7, "libweston/backends: Move damage flush into backends"
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
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>
