Commit Graph

25 Commits

Author SHA1 Message Date
Derek Foreman
c0cafde80f drm: Remove destroy listener from list when fired
Looks like we missed this one during the conversion to
weston_signal_emit_mutable.

Found by running weston under valgrind and running/killing
weston-simple-dmabuf-egl

Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
2022-06-03 09:58:09 +03:00
Marius Vlad
b0257e0ffc backend-drm: Add GBM_BO_HANDLE as a failure reason
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>
2022-06-01 07:38:17 +00:00
Marius Vlad
7412a01437 backend-drm: Retrieve reason if dmabuf import failed
As we could have situations where dmabuf import failed when attempting
to figure it the framebuffer is scanout-capable, make sure we also have
a way to store that information. Otherwise, we could end up
NULL-dereferencing, as we don't provide a valid storage for it.

Further more, with this, we also print out the reason why it failed, to
aid in further debugging.

Observed on platforms where GBM_BO_HANDLE failed + in combination w/
direct-display proto extension.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2022-05-30 16:22:35 +03:00
Daniel Stone
c54eace91d pixel-formats: Rename addfb_legacy_depth
'depth' isn't actually used to determine the bit depth of meaningful
components generally, but specifically to determine whether we can use
the legacy drmModeAddFB (pre-AddFB2) with those formats.

Rename the member to make it more clear what it's used for.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2022-05-20 11:24:41 +00:00
Robert Mader
29d480813a backend-drm: Add failure reasons for failing gbm_bo_import
And add it to the list of failures triggering a resend of
dmabuf feedback scanout tranches.

Closes https://gitlab.freedesktop.org/wayland/weston/-/issues/614

Signed-off-by: Robert Mader <robert.mader@collabora.com>
2022-05-12 11:53:04 +00:00
Daniel Stone
e9c792ed64 backend-drm: More failure reasons
Signed-off-by: Daniel Stone <daniels@collabora.com>
2022-04-25 14:27:08 +00:00
Daniel Stone
fef8bb275c weston_buffer: Make use of weston_buffer->type
Rather than calling accessors (wl_shm_buffer_get etc) to figure out
which type our buffer is, just look in the structure.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2022-04-25 14:27:08 +00:00
Daniel Stone
26c2f9a65f backend-drm: Don't try cursor buffers for client planes
For better or worse, cursor planes can only be used by uploaded SHM
buffers right now, so ignore them when we're calculating the acceptable
plane mask for client dmabufs.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2022-02-01 23:12:11 +00:00
Daniel Stone
57d609a47e backend-drm: Cache fb<->plane format compatibility list
Walking the format/modifier list to try to find out if our FB is
compatible with the plane is surprisingly expensive. Since the plane's
capabilities are static over the lifetime of the KMS device, cache the
set of planes for which the FB is theoretically
format/modifier-compatible when it's created, and use that to do an
early cull of the set of acceptable planes.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2021-12-08 13:38:18 +00:00
Daniel Stone
7d27df4c4c backend-drm: Cache drm_fb for each weston_buffer
When we first create a drm_fb from a weston_buffer, cache it and keep it
alive as long as the buffer lives. This allows us to reuse the gbm_bo
and kernel-side DRM framebuffer, rather than constantly creating and
destroying them at every repaint. The overhead of doing so (e.g. MMU
updates) can be significant on some platforms.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2021-12-08 13:38:18 +00:00
Daniel Stone
2ecc38b042 backend-drm: Move fb -> buffer reference to plane state
Currently each drm_fb takes a reference on a client buffer it wraps.
This prevents us from being able to reuse a drm_fb in multiple places
(e.g. two views of the same client buffer) simultaneously, or even back
to back.

Move the buffer reference to the plane state, as preparation for
allowing drm_fb to be cached inside the weston_buffer.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2021-12-08 13:38:18 +00:00
Daniel Stone
267f6cc6a1 backend-drm: Move drm_fb reference to state-propose
Currently we take a reference on the underlying client buffer every time
we materialise a drm_fb from a view, and release it when the drm_fb is
destroyed. This means that we need to create and destroy a drm_fb every
time we want to use it, which is pathologically unperformant on some
platforms.

To start working towards being able to cache drm_fb, only take the
reference when we apply it to a plane state.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2021-12-08 13:38:18 +00:00
Leandro Ribeiro
0a7034c0cb backend-drm: keep track of the reason why promoting view to a plane failed
Add enum try_view_on_plane_failure_reasons to help us to keep track of
the reason why promoting view to a plane failed. We also add a variable
to struct weston_paint_node so that we can update this information in
each output repaint.

This will be used in the next commits, in which we add proper surface
dma-buf feedback support.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
2021-11-25 11:16:21 -03:00
Emmanuel Gil Peyrot
eff793ab46 Fix indentation all through the project
Fixes a “regression” from 04918f3b0b, but
also other missed pieces.
2021-07-31 15:28:20 +00:00
Leandro Ribeiro
3193ab5807 backend-drm: simplify compile time array copy
In drm_fb_get_from_dmabuf() we have some compile time array copies, and
multiple static_assert() calls are needed (for safety). This makes the
code unpleasant to read.

Add ARRAY_COPY macro, to simplify the code.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2021-04-27 19:00:38 -03:00
Leandro Ribeiro
5aea1bc522 backend-drm: do not import dmabuf buffers with no modifiers to KMS
We can't tell the layout of a buffer that has been allocated with no
modifiers. Although usually drivers use linear layouts to allocate in
these cases, it is not a rule. It can use a tiling layout, for instance,
under the hood.

So it is not safe to import a buffer with no modifiers to KMS, as it
can't tell the buffer layout and this may result in garbage being
displayed. In this patch we start to require explicit modifiers to
import buffers to KMS.

In most cases things just work as expected, but just because both sides
(display and render driver) usually end up using the linear layout when
modifiers are not exposed. It also works on systems where the display
and render devices are tied (desktops with Intel or AMD, for instance),
as there's only one driver and it knows the layout of the buffer (no
need to guess).

But in SoC's where the display and render device are split, things can
go wrong. It is better to lose performance and not break things. To
solve the problem, drivers should be updated to expose modifiers (even
if only DRM_FORMAT_MOD_LINEAR), as the concept of implicit modifiers is
the root of the problem.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2021-04-27 19:56:38 +00:00
Pekka Paalanen
4b301fe7f2 Add weston-drm-fourcc.h
This header is for sharing fallback definitions for drm_fourcc.h. A new
test in tests/yuv-buffer-test.c is going to be needing XYUV8888 format,
and more new formats will be expected with HDR supports.

Share these fallback definitions in one place instead of copying them
all over.

All users of drm_fourcc.h are converted to include weston-drm-fourcc.h
instead for consistency: have the same definitions available everywhere.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-02-25 14:35:03 +02:00
Leandro Ribeiro
6196b201be backend-drm: remove unecessary ifdef checks
Since commit 28d26483 ("build: bump libdrm requirement to newer version
(2.4.83)"), all supported libdrm versions provide modifier formats,
atomic API and blob formats. Remove ifdef checks (HAVE_DRM_ADDFB2_MODIFIERS,
HAVE_DRM_ATOMIC, HAVE_DRM_FORMATS_BLOB) to improve the code and make it
simpler.

Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
2019-11-23 09:57:52 +00:00
Marius Vlad
81bada58db backend-drm: Add dmabuf scan-out check for DRM-backend
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2019-11-21 14:07:54 +02:00
Nicholas Niro
7aab746b3a backend-drm: Added support for legacy fd_import
This patch reenables the function drm_fb_get_from_dmabuf but with legacy
fd_import support for gbm/mesa < 17.1.
2019-11-12 13:01:02 -05:00
Nicholas Niro
56d1f4e7bc backend-drm: Fix for gbm modifiers when they are not available.
When the HAVE_GBM_MODIFIERS is unset, make the code drop back
to a single plane version like other places in the code.
2019-11-12 12:57:09 -05:00
Stefan Agner
ccf24076dd backend-drm: make GBM optional
Make GBM optional in case GL renderer is disabled. This allows to
build Weston with DRM backend without Mesa dependencies.

Signed-off-by: Stefan Agner <stefan@agner.ch>
2019-10-25 15:32:07 +02:00
Daniel Stone
d32dfcf833 backend-drm: Enforce content protection for hardware planes
62626cbfec ensures that the GL render will not render a view's content
to the screen when the surface has requested a higher content-protection
level than the output currently offers.

When the HDCP MR was split into the core content-protection support in !83
and specific DRM support for HDCP in !48 (not yet landed), this opened a
hole where the DRM backend could promote a view to a hardware plane,
even if the output offered a lower protection level than the surface
wanted to enforce.

In the DRM backend, check the desired protection level, and refuse to
promote the view to a hardware plane if the output does not offer
sufficient protection. This will lead to presentation falling back to
the renderer, which may censor the content, reduce quality, etc.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 4b6e73d617 ("libweston: Add support to set content-protection for a weston_surface")
2019-08-23 20:51:43 +00:00
Stefan Agner
5dd3e9996a backend-drm: drop gbm.h from c files
The header file is anyway included in drm-internal.h, we can safely
drop it from the c files.

Signed-off-by: Stefan Agner <stefan@agner.ch>
2019-07-08 00:35:06 +02:00
Daniel Stone
7580b3c09e compositor-drm: Move FB handling to a separate file
Move everything to do with creation, destruction, and reference handling
of drm_fbs to a new file.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2019-06-26 23:08:36 +01:00