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>
This reverts f843ba34d1 ("drm-backend: limit
reset/restart to output of a failed commit") and actually solves the problem
correctly.
The pending_state is no longer valid at this point, so it cannot be used to
determine the outputs of the current commit. So only clear will_repaint when
starting to repaint, so it can be used to determine which outputs of a device
were actually repainted and use it to reset/restart those outputs.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
After c08a6ff8 moved attach to the render loop, we have a bad situation
when clients delete an attached shm buffer. We try to query the stride
at attach time, but the shm_buffer has been destroyed, and we crash.
Instead of carefully fixing that, I've instead stored the stride at
buffer creation time (as we already do with buffer width and height).
This lets attach succeed in the gl-renderer, keeping the old texture data
available for any upcoming rendering.
Fixes: #927
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Tested-by: Connor Abbott <cwabbott0@gmail.com>
This most likely is a driver fail, as we shouldn't be getting a zero
value for max_brightness. Later on, this will be used to compute a
normalized brightness which would trip a with a division by zero.
Rather than fixing that up, just don't enable backlight support and
reportat that to the user that we have an invalid max_brightness value
and not backlight support.
Fixes: #878
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When a commit fails, then only the outputs that where part of this commit should
be reset or restarted.
Otherwise an unrelated output that has another successful pending commit may be
restarted incorrectly. Then the output is in an inconsistent state and will
trigger an assertion:
weston: ../libweston/backend-drm/state-propose.c:627: drm_output_propose_state: Assertion `!output->state_last' failed.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Currently only the return value of the last backend that implements
repaint_flush() is actually used. That only works because the drm backend is the
only backend that implements repaint_flush().
In the drm backend only the return value of the last device is used. And if a
failure is actually detected, then all repainted outputs of all backends are
reset. This can trigger asserts:
weston_output_schedule_repaint_reset() (or _restart()) will change the state of
the output but the backend that did not cause the failure will still call
weston_output_finish_frame().
The same thing can happen with multiple devices in the drm backend. Or outputs
get stuck if an error is dropped.
Since the drm backend is the only one that implements repaint_flush() anyways,
move the failure handling into the backend and make it device specific.
This way only the outputs that need it are reset.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
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>
Devices created via drm_device_create have this hash table, but those
created via drm_backend_create don't.
Signed-off-by: Ray Smith <rsmith@brightsign.biz>
We've forgotten to set this up in some backends, so let's just do it in
weston_compositor_init_renderer().
The headless backend used to fail out if linux_dmabuf_setup() failed, but
had no reason to do so, so just remove that to make the code common.
Suggested by cwabbott on irc.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
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>
Based on KMS "Colorspace" connector property, populate the mask of
supported colorimetry modes on a head.
EDID should be checked too, but it is currently ignored.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Avoid memory use-after-free when the trying to remove entries from an
already freed list later.
Also add missing removal in drm_output_detach_head() and drm_head_destroy().
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
I want re-use this variable for printing the colorimetry mode list as
well in a future patch, so a generic name is less confusing.
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>
Just like we already do for planes with proper zpos. Otherwise we'll
often end up choosing the primary plane instead of an overlay one
in `drm_output_find_plane_for_view()`.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
The `drm_output_deinit` should use the drm device passed by the
function, should not use the `b->drm` device.
Signed-off-by: Zhou Liang <174381115@qq.com>
If both the head and writeback are not found, then we should add
connectors to the drm device passed by the function, not the b->drm
device.
Signed-off-by: Zhou Liang <174381115@qq.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>
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>
This reverts commit 55bf6b5046.
This accidentally removed things that should have stayed - libseat
can still use the logind API, even if weston doesn't directly use
it.
Note that the logind-launcher does not actually build anymore
because breaking changes landed before this revert.
Since we're removing it again right away, I've not taken care to
fix that.
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>
This has been deprecated and non-default for a full release cycle, so
we're going to remove it now.
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>
We don't need to do this, we can just leave them in the plane list until
they're used.
Also, doing so helps for when we want to move the primary_plane from
the compositor to the outputs in the future.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Right now every backend clears output damage from the primary plane when
it repaints. Instead of having this same operation spread across all
the backends, just do it in the core instead.
In the future, we want to remove damage tracking from the primary plane
entirely, and this is a small step in that direction.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
A video mode change would be needed to change the underlying renderer
framebuffer. All other backends make uses of this so let's do it for the
DRM-backend as well.
This would also be needed for the output capture to function properly as
we need call weston_output_update_capture_info() when a new mode set has
set. Otherwise we'd run into mismatched dimensions for the current mode
versus the dimensions set-up initially in weston_output_capture_source_info.
Signed-off-by: marius vlad <marius.vlad@collabora.com>
If we want to support multiple backends, the compositor must take care
to call this once, at the appropriate moment, so stop letting the
backends handle compositor shutdown themselves.
Move the weston_compositor_shutdown() calls from the backend::destroy
callbacks into weston_compositor_destroy() and the calls in the backend
creation error paths into weston_compositor_load_backend().
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a weston_backend::shutdown callback to split out the part of
weston_backend::destroy that needs to be done before compositor
shutdown.
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>
Since 2d70bdfdcd "drm-backend: add support
to output capture writeback source", the DRM-backend was broken for KMS
devices that do not support the atomic API. This fixes that.
We don't support writeback screenshots without atomic modeset support.
So for such devices, we never update the output capture info
(weston_output_update_capture_info()) for the writeback source.
The function that we use to pull writeback tasks
(weston_output_pull_capture_task()) asserts that the capture providers
(renderers, DRM-backend) did not forget to update the capture info
(size/format) if something changed. But as we've never updated the
capture info for such devices, it is zeroed, leading to an assert hit.
With this patch we only pull the capture task for KMS devices that
support the atomic API.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In 2d70bdfdcd "drm-backend: add support to
output capture writeback source" we've ensured that disable_planes
should be false in order to support writeback capture tasks.
But this was wrong; disable_planes is transient (it is true when
there's some sort of content recording happening), and we enable/disable
that during compositor's lifetime.
This is dangerous and may result in a crash. Imagine the following
sequence:
1. screen recording starts, disable_planes is set to true.
2. for whatever reason the output size changes, and we end up
not updating capture info because we think that writeback is not
supported by the device.
3. screen recording stops, disable_planes is set to false.
4. user tries to take a writeback screenshot, and the
DRM-backend will pull a writeback capture task with
weston_output_pull_capture_task().
5. this function has an assert to ensure that the DRM-backend
did not forget to update the capture info, and we hit that
assert.
With this patch we drop disable_planes being false as a condition to
support writeback. So now we keep the capture info up-to-date even when
screen recording is happening, and we gracefully fail writeback tasks.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The session_listener is embedded in the DRM backend structure.
Use this to obtain the DRM backend with container_of().
That way the DRM backend will not have to be found from the compositor.
This is trivial now, but in the multi-backend case would entail
iterating over all backends to find the correct one.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.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>
wl_array_for_each() returns a pointer to each storage location; as we're
storing a pointer to drm_fb, this means that we have a drm_fb **, not a
drm_fb *.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We have an optimization to skip composition if there's no damage on the
primary plane and we already have a renderer buffer active. But we don't
allow this optimization if there's a pending capture task for the
output. For the renderer-based sources, that is really necessary, but
for the writeback source we should allow this optimization.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
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>
With this change, we expose the DRM-backend writeback source through the
output capture interface, making it available to clients.
For now we'll always fail writeback screenshots requests, because we
still don't have the writeback screenshooter implementation on the
DRM-backend. We add that in the following commits.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
