We can use __VA_OPT__ to make a macro that automatically selects between
the puts and printf log scope variants.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The paint_node life cycle should match the output's, so we should be able
to store it in the state instead of a view.
This gets us closer to having the backends stop caring about views.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We already validate the paint node list in weston_output_repaint,
immediately after we conditionally rebuild the z_order_list.
These asserts are thus completely redundant, as we've already
performed them in the front end.
My reason for removing this now is to drop weston_view usage
from the backend.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The paint node early update has already checked this value for us, we
should use that instead of interacting with the view.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Backends work on paint nodes, not views - and the paint node internal
name is a superset of the view internal name anyway, so it's not hard to
figure out which view a paint node belongs to when reading debug text.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The failure reason is already part of the paint node, so passing the view
here just makes things a little bit more complicated.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Backends should be relying on paint nodes for their information, not
views.
Since we always have a paint node when we want to pass a buffer, we can
pass that instead of a view.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We shouldn't need to test state, because the state that worked previously
should work again. However, to be completely safe against unpredictable
edge cases, we've kept a state check.
Remove that check and instead force a state rebuild in the case of an
application failure.
Keep track of how often this happens so we can fall back to checking
instead of consistently failing state application.
fixes#1081
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
If we're in a steady state, doing nothing but flipping buffers, we can
try to avoid going through our full routine of brute-forcing an
acceptable plane state, by instead just reusing the old state and
changing only the FB it refers to.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Derek Foreman <derek.foreman@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>
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>
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>
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>
No functional change, just move the comments in the else branch.
Added with 5429302e, ("backend-drm: add KMS plane's formats to
per-surface dma-buf feedback").
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Before, these pieces of code were allocating, formatting and freeing the
bit flags string regardless of whether debug logging was used or not.
Now, the bit flags string is formatted only when debug logging is
active, and it does not involve malloc+free.
This should improve performance a bit.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The only difference is a small one in the debug print, otherwise this is
completely identical.
Makes drm_pending_state_apply_atomic() slightly more maintainable.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
