Writeback connectors often support multiple formats, fully independent
of the input framebuffer. Wire up support for querying formats and send
them to clients.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
This converts weston_matrix and weston_vector to use linalg-types
internally. All direct accesses to members had to be converted
everywhere, mostly in the simplest form possible which leaves some
trivially reducable code around.
The intention is that we can now gradually migrate away from
weston_matrix in the future.
Look like one trailing space got accidentally annihilated in
compositor.c.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add asserts ensuring that outputs aren't created or destroyed twice
and that a valid pair of output/renderbuffer is passed to
repaint_output().
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
renderbuffer_get_image() is only used by the X11 backend to retrieve
the size of the renderbuffer. The previous commit assumes that
renderbuffers are created at the size of the associated output so the
renderbuffer size can now be retrieved from the output.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.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>
Move the responsibility for damaging the entire area of new
renderbuffers from backends to renderers.
There's one little drawback: VNC damage logging can't log the
accumulated renderbuffer damage anymore, but I guess this should
somehow be done as an option in the renderers.
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>
These were only necessary to allow surface_copy_content to return contents
that included recently attached (but not yet rendered) buffers.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Instead of attaching and flushing damage when performing
weston_surface_copy_content, just return the contents as the renderer
currently knows them.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
After c08a6ff8 moved attach to the render loop, we have a bad situation
when clients delete an attached shm buffer. We try to query the stride
at attach time, but the shm_buffer has been destroyed, and we crash.
Instead of carefully fixing that, I've instead stored the stride at
buffer creation time (as we already do with buffer width and height).
This lets attach succeed in the gl-renderer, keeping the old texture data
available for any upcoming rendering.
Fixes: #927
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Tested-by: Connor Abbott <cwabbott0@gmail.com>
Moving attach to the render loop in c08a6ff8bd
caused this to crash if the shm buffer is destroyed between being committed
to a surface and being rendered.
Since we don't keep a reference to the buffer pool anyway, we might as well
just skip the attachment here.
Fixes: #922
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Since we only call this from the paint node update code now, we can pass
the paint node directly.
A bit of internal refactoring is required to support copy_content.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Instead of doing this in several places, just do it when we're updating
the paint nodes in the repaint loop, or when we're about to copy
content via weston_surface_copy_content().
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Currently we're passing in a surface, a buffer, and an output. All of
these things are available in the paint node.
Further, if we pass in the paint node directly, we don't have to walk
a list of paint nodes to figure out if the texture is used in the
upcoming repaint.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When flush_damage() is called, the output to be repainted next is
already known. Pass it along into the renderer, which can make use
of this information:
The GL renderer can get a better idea which SHM surface textures
actually have to be updated, in case a surface can be put on a plane
on one output, but not another.
A future Vulkan renderer could record texture uploads into an output
specific command buffer.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
The primary_plane is currently shared amongst all outputs, and is the last
barrier to having overlapping outputs.
Split it up and make it per output instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Tracking the view's plane in the paint node in this way is a step towards
inflicting plane damage from paint node update during the output repaint,
instead of manually doing weston_view_damage_below().
We remove view->plane entirely and do all access through pnodes.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that we have visibility for views, we can clip that to an output
and store it in paint nodes.
This requires us to split the paint_node_update() function into two,
one for things that need to be done before assign_planes() and
one for after.
This will eventually be useful for tracking damage with paint nodes,
as we'll need to damage a paint node's entire visible area for
some operations.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Later, we'll want to use the visible region for damage tracking in
paint_nodes. For now, we can use it in the renderers where they've been
calculating it independently to draw paint nodes.
We still can't remove view->clip entirely, because
weston_view_damage_below() may be called before the first render of
a view, when its visible region hasn't been calculated yet. The
clip is empty at that point, which allows weston_view_damage_below()
to "work".
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Add a to_pixman_renderbuffer() helper to consolidate the
container_of(renderbuffer, ...) macro calls.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Now that struct weston_renderbuffer is refcounted, hold a reference for
renderbuffers on the pixman_output_state::renderbuffer_list. This allows
backends to destroy the renderer output state and release renderbuffer
references in any order without running into an assert().
To avoid breaking resizing, We also have to drop the renderbuffer list
during pixman_renderer_resize_output(). The backends have to create new
renderbuffers afterwards.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Update users of the old coordinate space conversion functions that take
x, y pairs to the new weston_coord versions.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Use struct pixel_format_info pointers instead of pixman_format_code_t
values at the API surface for output and image creation.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add weston_renderbuffer_ref/unref() functions and use them to
eventually destroy the weston_renderbuffer. Drop the explicit
renderbuffer_destroy vfunc from the pixman renderer interface.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Given that pixman_image_create_bits_no_clear() is asked to allocate the
buffer on its own, the _no_clear part is not important. Drop it.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Move the call to weston_output_update_capture_info() from the headless
backend into pixman_renderer_output_create(). For this, add an
uint32_t drm_format parameter to struct pixman_renderer_output_options.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Let weston_output_update_capture_info() take a uint32_t drm_format
parameter directly instead of const struct pixel_format_info *format.
No other fields apart from the format were used from this structure.
Without this, callers may have to unnecessarily look up the pixel
format info in cases where the DRM fourcc is already available.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a private struct pixman_renderbuffer that derives from struct
weston_renderbuffer and move the pixman renderer specific image and link
fields into it.
Add a pixman_renderbuffer_get_image() helper for the backends that need
to access the contained pixman image, RDP and X11.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a damage region to struct weston_renderbuffer and use it to replace
the previous_damage tracking in the drm backend.
Keep renderbuffers on a list in struct pixman_output_state and use it
to accumulate damage on all renderbuffers during repaint_output.
Now renderbuffers have to be created when pixman output state already
exists.
Reorder renderer output state and renderbuffer creation accordingly.
With this, pixman_renderer_output_set_hw_extra_damage() can be removed.
This can not yet replace the external damage tracking in the VNC
backend, which needsto know the accumulated damage that is not returned
from repaint_output.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a struct weston_renderbuffer parameter to repaint_output and make
backends set the pixman image renderbuffer through this parameter
instead of using pixman_renderer_output_set_buffer()
Turn pixman_renderer_output_set_buffer() static.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a create_image_from_ptr vfunc to struct pixman_renderer_interface,
which wraps weston_renderbuffer creation for the pixman renderer via
pixman_image_create_bits(), as well as a renderbuffer_destroy vfunc
to dispose of the pixman image renderbuffer.
Also add create_image_no_clear using pixman_image_create_bits_no_clear()
instead.
Make the backends create and destroy their pixman image renderbuffers
through this interface.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a struct pixman_renderer_interface with output_create and
output_destroy vfuncs and store a pointer to it in struct
weston_renderer.
Make all backends access the pixman_renderer_output_create/destroy
functions through this interface and turn them static.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Move the renderer type from struct headless_backend into struct
weston_renderer to store the chosen renderer type in a unified manner.
This will later allow secondary backends to determine the renderer type
chosen by the primary backend.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This services output capture tasks for the 'framebuffer' and 'blending'
pixel sources.
Just like the old screenshooting path, the 'framebuffer' pixel source is
the hardware buffer, whether a shadow is used or not. This may not be
the best for performance, but you do get the real framebuffer contents.
Maybe it's rgb565, or even less.
When the shadow buffer is used, I realized it is effectively the same as
the intermediate blending buffer in GL-renderer when color management is
used. Pixman-renderer does non-linear blending only, so the shadow
buffer is in the blending space. The shadow buffer is also always 8 bpc
regardless of the hardware framebuffer, so the read-back may be
different from the hardware framebuffer. Read-back from the shadow is
optimal for performance, but not what the hardware gets.
'full-framebuffer' source cannot yet be implemented, because backends do
not tell Pixman-renderer about the margins where the wayland-backend
blits the output decorations. The target "hardware" buffer handed to
pixman-renderer does not allow accessing the decorations area.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Mimic the existing behaviour of logging once, but make it once
per output instead of per run.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This will make sure that backends do not forget to tell us about
resizes.
composite_*() functions still read the size from the destination buffer,
because pixman_output_state is not available there.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In a journey to decouple renderer from weston_output, pass the initial
framebuffer size to Pixman-renderer explicitly.
Now Pixman-renderer will never look into weston_output::current_mode.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is necessary if you want to resize a Pixman rendered output that
uses the shadow.
Also reset the current hw_buffer to NULL, because surely it needs to
change and we don't want to keep an old buffer live for no reason if
there happens to be one.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Previously renderers were not told when the output (framebuffer they
need to draw) size changed. Renderers just pulled that information out
from weston_output::current_mode when they happened to need it. This
makes some things awkward, like resizing the shadow or intermediate
buffers. In fact, Pixman-renderer does not even support resizing its
shadow buffer, nor does GL-renderer. DRM-backend has to destroy and
re-create the renderer output state anyway, but rdp, x11 and wayland
backends would be natural users of resizing API.
This commit adds an API for resizing with empty implementations. Actual
implementations will be added in following patches for each renderer
while moving parts of resizing code from backends into the renderers.
No-op renderer needs no implementation.
Only wayland-backend has actual resizing code already, and that is made
to call the new API. Unfortunately, Pixman and GL renderers differ: one
does not blit them while the other does. In order to assert the
functionality of each renderer to keep the API consistent,
wayland-backend needs to lie to pixman-renderer. That's not new, it
already does so in wayland_output_get_shm_buffer() where the 'pm_image'
addresses only the interior area instead of the whole buffer.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Rename weston_output_region_from_global to weston_region_global_to_output,
and also no longer modify in place.
Trying to make it look a little nicer, as well as making it easier to use
from other places that don't want modify in place semantics.
This becomes a very thin wrapper around weston_matrix_transform_region.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Everywhere we are standardising to drm_fourcc.h pixel format codes, and
using struct pixel_format_info as a general handle that allows us to
access the equivalent format in various APIs. In the name of
standardisation, convert weston_compositor::read_format to
pixel_format_info.
Pixman formats are defined CPU-endian, while DRM formats are defined
always little-endian. OpenGL has various definitions. Correctly mapping
between these when the CPU is big-endian is an extra chore we can
hopefully offload to pixel-formats.c.
GL-renderer read_format is still defined based on Pixman format, because
of the pecualiar way OpenGL defines a pixel format with
GL_UNSIGNED_BYTE. That matches the same Pixman format on big-endian but
not the same drm_fourcc.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
