Rather than passing a NULL use sizeloc to pass the size. Otherwise
fflush(3) and fclose(3) would die out crashing in libc.
Use size also when printing out to a subscriber.
Fixes: e9665ef36
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Fix the following error:
Generating doc/sphinx/weston-doc-breathe with a custom command
FAILED: [code=1] doc/sphinx/weston
doc/sphinx/run_doxygen_sphinx.sh
/home/pq/git/weston/libweston/compositor.c:10001: error:
Found non-existing group 'client' for the command '@ingroup',
ignoring command (warning treated as error, aborting now)
Fixes: df622cbb20
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This tests our dma-buf buffer support for GL screenshots. We use two
backends that have outputs with different y origin in order to exercise
the implementation.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This ensures that output capture implementation is behaving accordingly,
but not that the screenshot result is correct. In the next commit we
add tests for checking that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the last commit we've added support for dma-buf screenshots in our
GL-renderer. So let's enable the screenshot client to use it.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This adds support for dma-buf screenshots in our GL-renderer.
For now it only supports GLES >= 3.0, as it depends on
glBlitFramebuffer(). In the future we'll add support for older GLES
versions as well, using a shader to do the blit.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
For now this doesn't bring any benefits besides making
gl_renderer_do_read_pixels_async() easier to read. But in the next
commits this will be important.
This allows callers to decide if they want to use a timer when they fail
to get a sync fence for a capture task. For SHM tasks we always fallback
to a timer, but for dma-buf we will not allow the fallback path.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
For now we support creating gl_capture_task only for SHM buffers. This
is used when the GL renderer pulls an output capture task from the
queue and its buffer type is SHM.
In the next commits we'll add support to allow output capture tasks to
be created with dma-buf buffers, so we need to extend gl_capture_task to
support that as well.
Differently from the SHM case, for dma-buf we don't have to do any copy.
The gl_capture_task is created just to wait for the blit to finish, and
then retire the output capture task.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This will be helpful in the next commits, in which we pass the buffer
type as parameter to a few functions. Adding the enum alow us to avoid
passing as unsigned int.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
All of these precede calls to weston_coord functions that now
do the transform update implicitly.
Some of them precede it immediately, and others through
functions like weston_pointer_set_focus and weston_pointer_send_motion
which use weston_coord_global_to_surface.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
I added these assert()s and have regretted it ever since. I'm sorry.
They've led to a bunch of places that just cargo-cult call
weston_view_update_transform() immediately after dirtying the transform,
as well as a lot of very carefully chosen places that took far too long to
sort out.
weston_view_update_transform() is an immediate return if the transform
isn't dirty, so let's just update them here instead of making everyone
think really hard about when to call weston_view_update_transform().
This should let us remove a few transform updates, and should
make the weston_coord functions a little easier to use.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We were missing using the build-and-test.sh script for cases
where we don't actually use it. Split it to call it appopriately,
including without setting ASAN's sanitize option for no-test jobs.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Now that only overlay planes are on the handle list, we can simplify this
code a little bit.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Some drivers allow a planes-only state as long as something covers
the entire CRTC, and some allow planes-only state even with only
partial coverage.
If we have an fb that we'd like to put on the primary plane, but can't,
we might as well try it on an overlay anyway and see if we can build a
planes-only state without a primary.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
While not as weird as the cursor plane, the primary plane's case is
pretty weird. Pull it out of the loop and handle it early.
This is really intended to be a step torwards building a planes-only
output state without a primary plane in it at all.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
There's no need to evaluate these in any particular order, but I'm
going to refactor all the check unrelated to underlays into a single
place shortly.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Trying to use an underlay will always fail if the output doesn't support
them, so add a quick check here.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
There's only one mode where we can skip the renderer, let's base the check
on that instead of checking for an existing scanout fb.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When a paint node is drawing rotated content, it's treated like its axis
aligned bounding box. Even if it only contains fully opaque content,
the parts of the axis aligned bounding box outside of that content
are not opaque.
We need to ensure we don't claim a paint node that isn't axis aligned
is fully opaque, or we'll improperly update regions outside of the
really opaque content.
Fixes 485e1796af
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
It makes more sense to update the transform than to bail.
These functions are sort of hints - they have to be correct when true, so
the previous code isn't really buggy. But they make more sense at a glance
this way.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The client-buffer test was setting the desired output refresh rate to
the highest possible, posting a new buffer to the screen, waiting for
the frame callback, then requesting a screenshot be taken.
This was not necessary (we already have a mode for tests which only want
screenshots and not a free-running refresh), and also harmful in that it
setting up a potential race.
When gl-renderer gets asked to repaint with nothing to show, it tries to
read back the GL fence status after the dmabuf has signalled. On drivers
with the threaded context enabled, the GL fence would not be readable,
even if the attached dmabuf was.
The easy fix to this is to just not free-run refresh.
Signed-off-by: Daniel Stone <daniels@collabora.com>
As weston_surface_attach_solid() can change quite a lot about a surface,
we need to mark it as dirty.
Signed-off-by: Daniel Stone <daniels@collabora.com>
transform_damage() returns an allocated set of quads; if a surface had
both opaque and blended regions, we were overwriting the
previously-allocated set of quads for the blended region.
Luckily, transform_damage() doesn't need to be called twice anyway, so
we can fix this by only calling it once in the first case.
Signed-off-by: Daniel Stone <daniels@collabora.com>
No behavior changes; this is a follow-up of "drm: handle client buffer
destroyed while writeback scheduled".
That commit protects against clients disconnecting while a writeback job
is scheduled, which could otherwise lead to crashes if the buffer is
destroyed before the wb job completes. However, output capture provides
the same functionality: it listens to the client buffer destroy event to
retire the capture task.
Instead of listening to the wl_buffer destroy event, simply listen to
the capture task destroy event. GL renderer already follows this
pattern, and now DRM aligns with it.
See also:
weston_capture_task_buffer_destroy_handler()
weston_capture_task_add_destroy_listener()
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
No behavior change, just a refactor to make it more clear that the state
is freed after the capture task is retired.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
YUV420_8BIT and YUV420_10BIT are special DRM formats, which exist to
allow for NV12/P010-alike formats having combined storage for luma &
chroma, rather than split planes.
This is notably used to support AFBC compression for YUV buffers, as
seen with at least Hantro codec engines and Mali GPUs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a way for weston-color to disable color-management, so we have a
simple single-pixel-buffer test.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Before "drm: make writeback format negotiation more robust", pulling a
writeback capture task while another writeback was in progress could
lead to a crash.
That commit avoids the crash, but it relies on
drm_output_find_compatible_writeback() to fail if a writeback task is
already in progress, as the majority of hardware probably support a
single writeback connector compatible with the CRTC.
Although unlikely, hardware may support more than one writeback
compatible with the CRTC. That would break our code, as our writeback
implementation does not support simultaneous writeback tasks per output.
This adds an explicit check and retires the writeback task if there's
already another writeback in progress.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently drm_output_get_writeback_formats() returns the formats
supported by a single writeback connector compatible with output->crtc.
This list is used to populate struct weston_output_capture_source_info
through weston_output_update_capture_info().
Later, when pulling writeback capture tasks, we call
drm_output_get_writeback_formats() again. However, as
drm_output_find_compatible_writeback() skips writeback connectors in
use, the returned format list may now differ.
Also, when selecting a writeback connector we implicitly rely on
drm_output_find_compatible_writeback() returning the same connector as
before, without verifying that the chosen connector supports the format
of the buffer provided by the client.
Make drm_output_get_writeback_formats() return the union of formats
supported by all writeback connectors compatible with output->crtc. This
makes the returned format list deterministic, regardless of whether a
writeback connector is currently in use. Although most hardware probably
supports a single writeback compatible with the CRTC, this is a good
change as it makes the code more generic and robust.
Also, add a new format param to drm_output_find_compatible_writeback(),
so now the the selected writeback can be validated against the requested
format.
The main benefit of this patch (and the reason why I wrote) is enabling
us to fix an issue when a writeback task is already in progress and
additional ones are requested:
1. weston_output_pull_capture_task() depends on the writeback format
list
2. if a writeback is already in progress,
drm_output_get_writeback_formats() returns NULL (assuming there's a
single writeback connector).
3. weston_output_pull_capture_task() crashes Weston, as the list of
writeback formats we pass does not match the one stored in struct
weston_output_capture_source_info.
With the format list now deterministic, we'll be able to safely pull the
capture task and retire it. The next commit implements this behavior.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This function does more than just checking if it should wait for
completion: it completes the screenshot if possible. So rename to avoid
confusion.
This also adds documentation to the function.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently when a client buffer gets destroyed, the output capture task
gets destroyed with weston_capture_task_buffer_destroy_handler().
The problem is that we may have a writeback task scheduled, so
wb_state->ct would be pointing to a ct that has already been retired
and destroyed.
In this commit we start handling this case.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Otherwise we would end up checking the output of the GL renderer, not
verifying that we set the DRM properties correctly.
Coincidentally this also seems to work around CI flakiness of the test.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
On drivers without explicit modifier support we can't use
eglQueryDmaBufModifiersEXT() to check the correct texture target. We
already hardcode GL_TEXTURE_EXTERNAL_OES for various YUV/YCbCr formats -
let's assume it applies to all of them.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Perhaps this would make things a bit more obvious to newcomers not
being familiar with historical 2D bitmap hardware sprite.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This disables all of the hardware planes not just overlay (primary and
underlays as well). Change also the debug message.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The intention is that you should be able to replace these with the
pipewire-backend that you can load together with the DRM-backend. The
functionality should be equivalent, but the libweston software
architecture becomes more maintainable for upstream. Also the
pipewire-backend is not tied to the DRM-backend, and can work with any
other backend and even alone.
Once the remoting and pipewire plugins are gone, we can remove the
virtual output API from DRM-backend.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
