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>
The outputs, heads, crtcs, and connectors are specific to a drm device and not
the backend in general.
Link them to the device that they belong to to be able to retrieve the
respective device.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The scanout format for the dma-buf feedback are specific to the kms device that
is used for scanout. Therefore, we have to pass the device of the output when
retrieving the scanout formats.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Extract the kms device from the backend to allow a better separation of the
backend and the kms device. This will allow to handle multiple kms devices with
a single drm backend.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
And use it to get a feedback event for when adding scanout tranche.
With this change, I get back a feedback event for dmabuf-feedback
on VC4:
���� tranche: target device /dev/dri/card0, scanout
� ���� format ABGR2101010, modifier LINEAR (0x0)
� ���� format XBGR2101010, modifier LINEAR (0x0)
� ���� format ARGB8888, modifier LINEAR (0x0)
� ���� format ABGR8888, modifier LINEAR (0x0)
� ���� format XRGB8888, modifier LINEAR (0x0)
� ���� format XBGR8888, modifier LINEAR (0x0)
� ���� format RGB565, modifier LINEAR (0x0)
� ���� format YUV420, modifier LINEAR (0x0)
� ���� format YUV422, modifier LINEAR (0x0)
� ���� format YVU420, modifier LINEAR (0x0)
� ���� format YVU422, modifier LINEAR (0x0)
� ���� format NV12, modifier LINEAR (0x0)
� ���� format NV12, modifier BROADCOM_SAND128 (0x700000000000004)
� ���� format NV16, modifier LINEAR (0x0)
� ���� end of tranche
Besides that, it can place a fullscreen state of simple-egl on the
primary plane, which without this change wasn't possible.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When we're checking to see if a view is suitable to go on a plane, check
for (and reject) solid-colour buffers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The Pixman renderer keeps its own reference to buffers when attached to
surfaces, through its surface state: just use that instead.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a mode argument to weston_buffer_reference which indicates whether a
buffer's storage may/will be accessed, or whether the underlying storage
will no longer be accessed, e.g. because it has been copied. This will
be used to retain a pointer to the weston_buffer whilst being able to
send a release event to the client.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The repaint_data is entirely backend specific. Moreover, it is only used by the
drm backend, while other backends ignore the repaint data.
There will always be only one repaint active, thus, there is no need to pass the
repaint data from the outside.
The repaint_data breaks with the multi-backend series, which calls repaint begin
for all backends to get the repaint_data. The repaint_data of the last backend
will then be passed to all other backend. At the moment, this works, because the
drm backend is the only backend that implements the begin_repaint call.
Another option would be to track the repaint data per backend in the compositor,
but actually, it the backend needs to track state across the calls, it's its own
responsibility.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The pending_state is already stored in the backend and can be directly retrieved
from there.
This avoids involving the compositor in passing state between the repaint
phases for a single backend.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Specifically log if there were no suitable planes for us to use, or if
we tried to place it on a plane but were told no by the kernel.
Signed-off-by: Daniel Stone <daniels@collabora.com>
There's no real reason for these to be separate now that the eligibility
checks have been moved up so we don't call them unless it makes sense.
Signed-off-by: Daniel Stone <daniels@collabora.com>
