We have a big bitfield of failure reasons for when we can't place a paint
node on a plane - but between the introduction of this bitfield and now
we added many new reasons, so it's an expecation that the reason
FAILURE_REASON_FORCE_RENDERER only means that the compositor is configured
to force the use of the renderer via the WESTON_FORCE_RENDERER environment
variable, or debug key bind, or similar.
Some of the code retained the older generic use of FORCE_RENDERER to mean
any number of things.
Add some new reasons and use other existing reasons to disambiguate the
FORCE_RENDERER reason.
Since we already print the (somewhat misleading) failure reason strings
late in the repaint pass, we can drop the (currently accurate) debug
prints we fired off along the way, and just print them accurately at the
end.
We also move the failure reason reset point to the start of repaint,
as it is convenient to have it be valid after plane assignment so
we can print it in scene graph debug text in a later commit.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The caller to drm_plane_state_coords_for_paint_node() has already tested
for valid transforms, so drm_plane_state_coords_for_paint_node() is never
called with a transform that needs to be tested.
Replace the test with an assert() - and this also lets us stop returning
a bool, and drop the debug prints that could never trigger.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
On weston_output_repaint(), we have:
output_assign_planes(output);
...
output->repaint(output);
output_assign_planes() avoids calling output->assign_planes() when
output->disable_planes > 0. This brings a few complications to backends,
because they can't rely on the repaint loop starting from a certain
function: sometimes it starts from assign_planes(), others from
repaint().
Let's be more consistent: always call assign_planes() and let backends
handle output->disable_planes.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
If we call drm_output_find_plane_for_view() with
DRM_OUTPUT_PROPOSE_STATE_RENDERER_AND_CURSOR for a view that is not a
cursor view, it should fail to get a plane.
In such case, set the failure reason to FAILURE_REASONS_FORCE_RENDERER.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the next commit we introduce a real "renderer-only" mode. So let's
rename DRM_OUTPUT_PROPOSE_STATE_RENDERER_ONLY to
DRM_OUTPUT_PROPOSE_STATE_RENDERER_AND_CURSOR, as it also assign views
to cursor planes.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
drm_output_propose_state() is called during from drm_assign_planes(). At this
point, the output is enabled, but it may be disabled in the current state, that
is copied.
So explicitly enable the output by setting dpms to WESTON_DPMS_ON.
The same thing is already done in drm_output_repaint() but that's to late for
drm_output_propose_state(). Move that to the fallback path when planes are
disabled. It's no longer needed in general and changing the state between the
atomic test and commit is not a good idea anyways.
Without this, the atomic commit may fail, even though the corresponding test was
successful.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
The sampler type, which was initially meant for the GL renderer, is
currently used to derive the color model of pixel formats. This commit
gets rid of this legacy field and replaces it with an explicit one
indicating the color model.
Note that it also fixes the issue that formats wouldn't be considered
YUV if ENABLE_EGL isn't defined because the sampler type field in that
particular case would always be 0.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Upstream KMS drivers currently default to either ITU-R BT.601 YCbCr or
ITU-R BT.709 YCbCr. Ensure consistent behavior by setting a default.
We use BT.601 as that is what our fallback shader uses at the moment.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Up to now, we've been logging only the failures that we get from
drm_fb_get_from_paint_node(). So let's start logging the other failures
we get in drm_output_find_plane_for_view() as well.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This should help people to debug. Instead of printing an hex value,
print each enum value present in the bitmask as a string (comma
separated).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Client won't be able to do direct-scanout with this surface, and the
format/modifier doesn't matter in this case. So let's remove the scanout
tranche from dma-buf feedback in such case.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently we have the following situation: we add a scanout tranche
because if the client re-allocates with another format/modifier, the
chances of being placed in a DRM/KMS plane is higher.
But then we run out of overlay planes. So we remove the scanout tranche,
because the format/modifier available in the renderer tranche are
optimal for rendering.
Now Weston detects again that the format/modifier is what may be
avoiding the view being place in a plane, re-adding the scanout tranche.
And we have an endless loop.
To avoid this, let's accumulate the reasons why placing the view in a
place failed. So if we detect that we don't have planes available, no
matter the format/modifier, we won't add the scanout tranche.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are a few points in the code where we are wrongly using
FAILURE_REASONS_ADD_FB_FAILED, probably because we didn't have so many
"failure reasons" previously. This update such cases to use enum's that
make sense.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Do not skip all the planes if a single one of them do not support
fences. The other may do.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Now that secondary planes can be both underlay and overlay, this flag's
meaning also changed. Update it for correctness.
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Previously, whether a KMS plane is underlay-able is determined by
whether it's zpos_max is < the primary plane's zpos_min. In other words,
a plane will only be considered underlay-able if its entire valid zpos
range is under the primary plane's lowest zpos.
This is too restrictive - it's possible for planes to have a valid zpos
range that spans below and above the primary's zpos range.
Therefore, allow planes to be used as underlays if their zpos_min is <
the primary plane's zpos_min.
In addition, force rendering on a view if it contains alpha, and is
occluded by a rendered view. If such a view is overlaid, it would render
with incorrect zorder. If it's underlaid, it would render with incorrect
alpha-blending due to hole-punching. Therefore, it must be rendered.
Force rendering prevents the view from going into
`drm_output_find_plane_for_view()`, which serves as an optimization, but
is also observed to prevent dmabuf feedback (derived from
`try_view_on_plane_failure_reasons`) from ping-ponging between two
values, causing some apps (like weston-simple-egl) to constantly
reallocate its buffers.
Because a plane can now - if supported - be used as an underlay, an
overlay, or both, add a `enum drm_plane_subtype` to differentiate
between them. Then, print it's subtype and underlay/overlay assignment
once a decision is made.
v2:
* Squash w/ patch to force rendering on alpha view occluded by rendered
view
* Bring back plane subtype enum to be more expressive about plane
capabilities
* Correct need_hole != false when a view's assignment changes from
underlay to overlay
Signed-off-by: Leo Li <sunpeng.li@amd.com>
We need to reset the underlay check inside the view evaluation loop,
otherwise once we need an underlay we'll treat every following view as
needing an underlay.
Fixes: 1065d23406 ("backend-drm: Improve plane assignment for underlay platform")
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fundamentally, the flags are a property of each paint node, rather than
each view as such. Move them over there so it gets a little less painful
to work with.
Signed-off-by: Daniel Stone <daniels@collabora.com>
1. remove the restriction on underlay planes when finding plane.
Because the view on the underlay plane can be displayed by drawing
a through hole on primary plane, so we can try underlay planes.
2. Add step to check if the view is assigned on underlay plane, When
it is successfully placed on a HW plane. Because we need to set the
underlay view pnode->need_hole to true so that gl-renderer
will draw a hole for it when repainting.
3. Avoid assigning views to underlay HW planes when the backend format
is opaque and avoid assigning views with alpha to underlay HW planes.
4. when overlay plane is not enough, try to find underlay plane on
platform with both overlay and underlay plane.
Signed-off-by: Chao Guo <chao.guo@nxp.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
On underlay platforms, the HW planes can be placed below the primary
plane, so some views that intersect with the renderer region can try
to be placed on the underlay planes. In order to assign these views
to underlay planes, the improvement is as follows:
1. Add current_lowest_zpos_overlay. Record the current lowest zpos
of the overlay planes.
2. Add current_lowest_zpos_underlay. Record the current lowest zpos
of the underlay plane. It is initialized to scanout_plane::zpos.
3. Add need_underlay to indicate whether to find underlay plane for
view.
4. The views that intersect with the renderer region and underlay
views should be assigned to underlay planes.
Signed-off-by: Chao Guo <chao.guo@nxp.com>
Doing this might cause unnecessary DRM importing, which might result in
an error when the DRM's memory address mapping is nearly full.
Return before attempting to create drm_fb to avoid that, since it will
fail in the later check anyway.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
If a view is non-opaque - such as an overlay over a video - we shouldn't
force it to be on the primary plane, as that's where the underlying
content should be placed, such as the video view.
dc0de9ee already mentioned: "This check should be changed in future to
only filter for opaque views, but that's for another time."
Adding "Fixes" at this is arguably a bug fix:
Fixes: dc0de9ee (backend-drm: Move overlay vs. primary plane check earlier)
Fixes: 2538aacc (backend-drm: Construct a zpos candidate list of planes)
Signed-off-by: Robert Mader <robert.mader@collabora.com>
We can't use the surface damage to determine when to upload new cursor
images because when heads overlap the first repainted head will accumulate
that damage as plane damage.
We can't easily use plane damage either because the plane isn't really
assigned until after an atomic test, which requires the cursor fb to be
current.
Untangle this mess a little by always testing with the first cursor fb,
which is identical to the second in all ways, then replace with the correct
fb in repaint.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that planes are attached to paint nodes, we no have no reason to
prevent placing a view on a plane when it's on multiple monitors.
Signed-off-by: Derek Foreman <derek.foreman@collabora.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>
We've just made this impossible, so we can now clean up all the TODO
locations.
I've only turned some of them into assert()s, because they're all mostly
in the same place.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We map view alpha(0.0-1.0) to plane state's alpha
by using the max plane alpha value got from drm.
Signed-off-by: Hsuan-Yu Lin <hlin@jp.adit-jv.com>
Signed-off-by: Veeresh Kadasani <external.vkadasani@jp.adit-jv.com>
Signed-off-by: Vinh Nguyen Trong <Vinh.NguyenTrong@vn.bosch.com>
We log the reasons why the fb of a certain view was not placed in an
overlay plane and use that for debug purposes. With these reasons we
also decide if the scanout tranche should be included on the dma-buf
feedback or not. For instance:
1. If the reason is the incompatibility between the format/modifier
pair of the fb and those supported by the KMS device, the scanout
tranche is added and feedback is re-sent (so that the client can
re-allocate with parameters that makes it eligible for direct
scanout).
2. If the reason is because we have no overlay planes available, the
scanout tranche is useless. So the scanout tranche is removed and
the feedback re-sent (so that clients can re-allocate with
parameters optimal for the render device).
Also, when we detect that a view is eligible for direct scanout, we
don't even consider sending new feedback, as our interpretation of the
dma-buf feedback spec was that we should avoid bothering clients with
new feedback when they are already hitting direct scanout.
After some discussions and clarifications regarding the spec, we've
realized that Weston should start to also include the scanout tranche
even when the compositor is able to place client's content on overlay
planes. Basically, because this gives a chance for clients to
re-allocate with the proper parameters (not only format/modifier pair,
but also the target_device and the flags) from the scanout tranche. In
this patch we start doing this.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
It makes no sense to keep the scanout tranche on the dma-buf feedback if
there are no overlay planes available. So start to remove it.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In this patch, we add the writeback connector screenshooter to the
DRM-backend.
This will be useful to create plane composition tests that will run in
our CI, as VKMS already supports writeback connectors.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Additional devices don't have a gbm device. Therefore, we cannot create gbm bos
for the cursor.
If the output device differs from the gbm device, fall back to the allocation of
a dumb buffer for the cursor on the output device. Update the cursor sprite with
a memcpy to the already mapped dumb buffer that belongs to the current cursor.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Search for planes that support the rotation required to properly display
a paint node, and properly set coordinates and rotation properties.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
It is only enabled by a debug key binding, currently not tested at all,
and is seems it doesn't really work, so let's remove it. This also
removes it from the man page.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Since b38b735e20, 'backend-drm: Remove Pixman conditional
for keep_buffer' the Pixman renderer keeps its own reference to buffers
when attached to surfaces, rather than flipping keep_buffer variable for
the surface. Problem is that when switching from the Pixman render to
the GL would not work and could result in a crash upon first repaint.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
There is missing dependency on linux-dmabuf-unstable-v1-server-protocol.h
header file in backend-headless, backend-drm and backend-x11. That files
do not depend on that header, in fact. But by this moment they've had
that implicit dependency due to linux-dmabuf.h header.
With specific set of meson configure options the protocol header is not
generated at the right time, what causes build error in 100% cases using
small amount of building threads (from -j1 to -j8).
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>
As a first step towards heterogeneous outputs, ignore other backends'
heads and outputs. This is done by checking the destroy callbacks for
heads and outputs.
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
If we have multiple drm devices, we cannot use the drm device from the backend,
because we would only get the primary device and not the device of the output.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
