We're going to add a way to reuse state, but we don't currently have a way
to represent invalid state - such as before we've ever commit any state
at all.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This will be handy later when trying to determine when it's ok to reuse
output state, as changing this would invalidate previous state.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Although Vulkan's renderbuffers are dmabufs, the difference between a
client dmabuf and a backend-allocated dmabuf is a very meaningful one.
Add a separate buffer type for BUFFER_DMABUF_BACKEND instead of
overloading BUFFER_DMABUF for this.
This tangentially allows the Vulkan renderer to do direct scanout of
client buffers in mixed mode.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If the client requests to take a screenshot using the writeback source
with a DMA buffer, Weston will get the framebuffer from that dmabuf
object and attach it to the writeback connector.
Original commit by Chien Phung Van.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Co-authored-by: Chien Phung Van <chien.phungvan@vn.bosch.com>
The initial drm backend implementation for Vulkan passes display device
allocated gbm bos directly to the renderer. This is a bit awkward since
it requires the renderer to maintain a custom output creation interface
and another code path for importing specifically gbm bos.
Since then, vulkan-renderer received support to use dmabuf renderbuffers
to support e.g. pipewire dmabuf, in an interface which is also common
with gl-renderer.
The dmabuf renderbuffer code path is similar to what the drm backend
implementation intended to do, so we can unify it to a single interface.
This has the advantages of requiring one less custom output creation
interface, as well as the renderer being able to handle the drm backend
through a single shared dmabuf renderbuffer path.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
While this is generally drm specific stuff, it's leaked into paint nodes
a little bit already.
Pushing it into the core gives us the ability to print failure reasons
in the scene graph debug text (in a future commit), which can be very
informative.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
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>
In this patch we allow offloading the post-blend color transformation
to KMS.
As KMS currently only supports to offload the transformation in a LUT,
this may result in precision issues. So this introduces the config
option "offload-blend-to-output", which is disabled by default.
This option requires "color-management" to be enabled, otherwise it is
ignored.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The plugins cms-static and cms-colord have been deprecated and removed
from our code. They were the only thing holding set_gamma() from being
removed. So remove set_gamma() from the code.
Users can have the same results tweaking the output color profile that
they use.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
A Vulkan renderer for weston, based on the GL renderer.
The goal is to impose the least requirements as possible on Vulkan
implementations, as to allow even Vulkan 1.0 (or early development)
drivers to run a Wayland compositor. Any additional features or
extensions are made optional if possible.
Currently supports drm, wayland, x11 and headless backends.
As of this implementation, this is still considered an experimental
renderer.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
when drm-backend debug scope is set.
This follows-up with the surface counter timer but because this is
buried in the drm-backend we make use the drm-backend scope if there's a
subscription to it and enable and arm the counter as well when that
happens.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This patch counts the page flips (either in atomic or legacy page flips)
for DRM outputs and prints them using the drm-backend scope.
Similar to the frame callback timer counter this installs a counter that
periodically computes page flips per a pre-defined interval.
This also includes a perfetto counter to display these in perfetto.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Turns out it seems we have a missed some spots when using the
weston-direct-display protocol.
Specifically we still seem to be attempting a dma buffer import which
ultimately can reach the GPU. This patch rectifies that in such a way
that we can actually provide a full scanout path for client's (dma)
buffers as to avoid hitting the GPU entirely.
Signed-off-by: Marius Vlad <marius.vlad@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>
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>
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>
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>
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>
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>
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>
Update the field returned by weston_head_get_display_info(). This makes
EDID di_info available to frontends.
Since EDID data has changed, then head device_changed must be true as
well, because di_info may expose all EDID information and not just what
we track in the backend.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add 'is_underlay' in drm_plane, which is used to indicate whether the
HW plane is below the primary plane at the Z position.
Add 'has_underlay' in drm_backend, which is used indicate that there
are underlay planes in drm backend.
Signed-off-by: Chao Guo <chao.guo@nxp.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
With multiple backends or devices repaint_begin/repaint_flush may be called even
if no outout of a device will be repainted. This results in an "empty" drm state
without any output.
The actual commit to the kernel is already skipped but the drm-backend log is
still filled with "Beginning repaint"/"repaint-flush" messages and the scene
graph.
Use the new prepare_repaint() callback to determine if a backend needs to be
repainted and only create the pending_state if necessary.
Exit early in repaint_flush()/repaint_cancel() when no pending_state was created.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Based on what is configured in weston_output, check and set the
colorimetry mode into KMS connector property "Colorspace".
This changes how video sinks interpret the pixels, and should allow
driving e.g. WCG monitors in BT.2020 mode.
This does not alter the pixel values themselves. That is the color
manager responsibility, and ultimately the responsibility of the
frontend and the end user to match the monitor driving mode with the
output color profile they chose.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This will allow me to use this header in libweston core to build a
single translation table between core enums, string names, and wdrm
enums.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Store the EDID data as-is, so that we can tell when the EDID blob has
changed. This is not too useful yet, because all the weston_head_set_*()
API raises the device_changed flag only if the information actually
changes. However, I want to expose the libdisplay-info di_info structure
through weston_head, and those cannot be (as) easily compared.
We need to know when the EDID blob changes, so we can call
weston_head_set_device_changed() appropriately when updating di_info.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In a multi-GPU environment, different cards may contain connectors with the
same ID, and drm_head_find_by_connector just use the connector_id to find
the connector, it may find the wrong connector.
Fix this by find the connector based on the drm device and connector id.
Signed-off-by: Zhou Liang <174381115@qq.com>
Currently we flush damage for the "primary plane" every repaint, but this
is folly.
The drm backend may skip rendering entirely if using an all-planes
composition. This could leave the renderer plane in a messy state if a
surface on an overlay plane disappears.
Instead, let the backends flush the primary plane damage when they know
they need to render.
Fixes#864
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Insert the backend into the weston_compositor::backend_list instead
of setting weston_compositor::backend. The compositor uses this to
determine that the backend is capable of being loaded simultaneously
with other backends.
The DRM backend can only be loaded as primary backend.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Before this patch, we would leak the drm_output if there was a pending
flip during shutdown.
Now we destroy the drm_output even if there's a pending flip (only
during shutdown, as we don't want to wait until flip completion to
destroy the output).
Also, it fixes a problem where weston_output_enable() is called right
after weston_output_enable() or weston_output_disable() and it could
fail to find available DRM objects (as they are only released after
the flip completion).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We previously had our own local variable for this, but now we can just
use the one in weston_compositor.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Now that this is used only internally in modes.c, move it there. It will
not be used with libdisplay-info.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This will make adding libdisplay-info as another EDID parser easier,
because libdisplay-info always returns malloc'd strings.
To make things easier to extend as well, I introduce struct
drm_head_info. The libdisplay-info case will likely return more
information than this in the future.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Currently, if a head is detached, the entire state of the device is invalidated
to make sure that the connector is disabled on the next atomic commit. Side
effect of the invalid state is that all planes are disabled on the next commit.
This includes planes that are used with a different head that is not part of the
next atomic commit. Disabling the planes of unrelated outputs causes a blanking
of these outputs until output is repainted and the plane is reenabled.
Store the detached heads in a list on the output and disable the connectors for
all heads in this list in the next atomic commit.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
When doing plane selection for an output CRTC check if the plane
already has a CRTC attached and if so prefer that plane only for
the corresponding CRTC.
This prevents changing a CRTC's primary plane when it is active
which is not allowed by the DRM framework.
Based-on-patch-by: Eric Ruei <e-ruei1@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
This checks whether plane alpha is supported.
We get range of alpha value supported for plane
which is required for mapping view's alpha(0.0-1.0)
with drm plane alpha. No functional change.
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>
In commit "drm-backend: add writeback connector screenshooter to
DRM-backend" we were failing the writeback screenshot when the DRM/KMS
driver would take longer than the atomic commit to finish. In this patch
we address such case.
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>
In the following commits we add a writeback screenshooter. For that,
we'll need the formats supported by the writeback connectors. So include
the supported formats in struct drm_writeback.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Add the --additional-devices parameter to Weston to add secondary drm devices
that will only be used as outputs, but not for rendering.
We can only fail the repaint for the entire backend, but not for single
devices. Thus, if one of the devices fail, we have to fail the repaint for the
entire backend.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
If the GBM bo was allocated on a different device than the device that is used
for the fb, we have to import the fd first and update the handle.
Use drmPrimeFDToHandle directly instead of using a gbm device for the scanout
device, since a gbm device would require a gbm implementation, which is often
not available for devices that only support scanout.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Weston uses a cached drm_fb when a view is shown multiple times. If the view is
shown on multiple outputs backed by different DRM devices, Weston returns the
cached drm_fb for the first device that was used for the import. This causes a
failure when adding the fb to the other device.
Use a list of all drm_fbs to cache the buf_fb per device, and check for the
device before reusing a drm_fb.
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>
For now we just always set the plane up to have a "normal" rotation, so
no new features are added with this commit.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
