Commit Graph

59 Commits

Author SHA1 Message Date
Michael Tretter
101c0f6b8b backend-drm: get the fb using the device instead of the backend
The fbs are specific to the device on which they will be displayed. Therefore,
we have to tell which device shall be used when we are creating the fb.

Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
2022-06-03 09:13:40 +02:00
Michael Tretter
0d967bd7f4 backend-drm: extract device from backend
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>
2022-06-03 09:12:57 +02: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
Pekka Paalanen
8ebebb20ef drm-backend: add color_outcome / HDR metadata serial
Output color profile may be changed in flight. Output basic color
characteristics and EOTF mode cannot yet be changed in flight, but it is
reasonable to assume they could in the future. Therefore the color
outcome data may change in flight as well, which is the basis for HDR
metadata, which needs to be updated as well.

Track the changes to color outcome data with a serial number.
DRM-backend checks the serial number to see if it needs to re-create the
HDR metadata blob. This allows the changes to propagate all the way to
KMS.

The code added here is more of a reminder of what should happen than a
tested path.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2022-05-27 10:30:35 +00:00
Pekka Paalanen
c4fedd503f backend-drm: move code to kms-color.c
This creates a new file for KMS related color code, to avoid making
drm.c even longer.

The moved code was just added in 5151f9fe9e
so the new file copyrights are written based on that.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2022-05-27 10:30:35 +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
Pekka Paalanen
5151f9fe9e backend-drm: program HDR_OUTPUT_METADATA
Program the connector property HDR_OUTPUT_METADATA based on the EOTF
mode of the output.

For now, this changes only the EOTF. The colorimetry and luminance are
left undefined, to be filled in by later patches. This should still be
enough to put a video sink into HDR mode, albeit the response is
probably unknown.

drm_output keeps track of the currently existing blob id. If the blob
contents need to be re-created, this blob would be destroyed and the
field set to zero. In this patch, there is no provision for runtime
changing of HDR metadata, so there is no code doing that.

Destroying the blob at arbitrary times is not a problem, because the
kernel keeps a reference to the data as long as the blob id remains with
KMS.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2022-05-02 12:19:24 +00:00
Pekka Paalanen
1d17e4991f backend-drm: check for HDR_OUTPUT_METADATA
Check whether HDR_OUTPUT_METADATA property exists on a KMS connector. If
yes, pretend that EDID claims support for all EOTF modes and update the
head supported EOTFs mask accordingly. If not, then only SDR is
possible.

Parsing EDID to take monitor capabilities into account is left for
later.

HDR mode cannot be set without HDR_OUTPUT_METADATA.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2022-05-02 12:19:24 +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
Michael Tretter
6ee6e76a0c compositor: remove repaint_data from compositor
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>
2022-04-06 12:47:05 +02:00
Daniel Stone
30de938624 backend-drm: Add more view-to-plane failure states
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>
2022-02-01 23:12:11 +00:00
Daniel Stone
e5ad3c8865 backend-drm: Remove separate zpos_plane list
When we introduced support for variable zpos, we did so by filtering the
list of acceptable planes and then creating a separate zpos-ordered
list. Now that the planes are already zpos-sorted in the backend list,
and we have more early filtering, we can replace this with a single
plane-list walk.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2022-02-01 23:12:11 +00:00
Daniel Stone
af42fc1e33 backend-drm: Assign plane_idx by plane list order
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
Leandro Ribeiro
5429302e78 backend-drm: add KMS plane's formats to per-surface dma-buf feedback
In commit "libweston: add initial dma-buf feedback implementation" we've
added initial support to dma-buf feedback, but it was not using the
feedback from DRM-backend to add useful per-surface feedback.

In this patch we add this. The scanout tranche of the per-surface
feedback is based on the union of formats/modifiers of the primary and
overlay planes available. These are intersected with the
formats/modifiers supported by the renderer device.

Also, it's important to mention that the scene can change a lot and we
can't predict much. So this patch also adds hysteresis to the dma-buf
feedback. We wait a few seconds to be sure that we reached stability
before adding or removing the scanout tranche from dma-buf feedback and
resending them. This help us to avoid spamming clients and leading to
unnecessary buffer reallocations on their end.

Here's an example of what we want to avoid:

1. We detect that a view was not placed in a plane only because its
   format is not supported by the plane, so we add the scanout tranche
   to the feedback and send the events.

2. A few milliseconds after, the view gets occluded. So now the view
   can't be placed in a plane anymore. We need to remove the scanout
   tranche and resend the feedback with formats/modifiers optimal for
   the renderer device. The client will then reallocate its buffers.

3. A few milliseconds after, the view that was causing the occlusion
   gets minimized. So we got back to the first situation, in which the
   format of the view is not compatible with the plane. Then we need to
   add a scanout tranche and resend the feedback...

This patch is based on previous work of Scott Anderson (@ascent).

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
2021-11-25 11:16:52 -03: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
Alexandros Frantzis
10937feef8 backend-drm: Clear drm_output cursor_view when view is destroyed
The DRM backend uses changes in the cursor view memory address and
surface damage to detect when it needs to re-upload to a cursor plane
framebuffer.

However, when a cursor view is destroyed and then recreated, e.g., when
the pointer cursor surface is updated, the newly created view may have
the same memory address as the just destroyed one. If no new cursor
buffer is provided (because it was attached, committed and used
previously) when this address reuse occurs, then there also isn't any
updated surface damage and the backend doesn't update the cursor plane
framebuffer at all.

To fix this issue utilize the destroy signal to track when the cursor
view is destroyed, and clear the cached cursor_view value in drm_output.
After clearing the cached value, the next cursor view is always
considered new and thus uploaded to the plane properly.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
2021-06-14 13:31:41 +00:00
Igor Matheus Andrade Torrente
bfcb1adc14 backend-drm: Drop support to non universal plane drivers
Remove all the backend code to support drivers without universal planes.

From[1]:

"The code needed to support kernels where DRM does not support uiniversal
planes makes the DRM-backend a little more complicated, because it needs
to create fake planes for primary and cursor. The lifetimes of the fake
planes does not match the lifetime of "proper" planes, which is surprising."

And since the universal planes left the experimetal flag in 2014[2] it is
safe to remove the support now.

[1] https://gitlab.freedesktop.org/wayland/weston/-/issues/427
[2] https://cgit.freedesktop.org/drm/drm-tip/commit/?id=c7dbc6c9ae5c3baa3be755a228a349374d043b5b

Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
2021-06-01 17:25:20 +00:00
Scott Anderson
7466309c12 backend-drm: start to use weston_drm_format in drm_plane
In commit "libweston: add struct weston_drm_format" struct
weston_drm_format and its helper functions were added to libweston.
Also, unit tests for this API have been added in commit "tests: add unit
tests for struct weston_drm_format".

Start to use this API in the DRM-backend, as it enhances the code by
avoiding repetition and ensuring correctness.

Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Co-authored-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
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
Maxime Roussin-Bélanger
35e34505ce backend-drm: fix typos
Signed-off-by: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com>
2021-02-24 10:01:07 -05:00
Pekka Paalanen
9b94a7d833 Bump libdrm dependency to 2.4.95
96bef0517e "drm-backend: add support for
writeback connectors" started using DRM_MODE_CONNECTOR_WRITEBACK and
DRM_CLIENT_CAP_WRITEBACK_CONNECTORS. These were introduced in libdrm
2.4.95.

According to
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/311
Ubunut Xenial is the only mentioned distribution that does not provide a
libdrm new enough. I think that is fine to drop now, 2016 was a good
while ago.

Libdrm 2.4.95 also introduced DRM_CLIENT_CAP_ASPECT_RATIO,
DRM_MODE_PICTURE_ASPECT_64_27, DRM_MODE_PICTURE_ASPECT_256_135.

The fallback definitions for the above are dropped.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2020-10-16 16:20:54 +00:00
Leandro Ribeiro
96bef0517e drm-backend: add support for writeback connectors
Recognize writeback connectors and add 'struct drm_writeback'
objects in order to store them.

These objects are created and stored in a list by the time
that DRM-backend is initialized. This list is updated if a
writeback connector dynamically appears or is disconnected.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2020-09-16 14:03:18 +00:00
Leandro Ribeiro
6794164bd9 drm-backend: move drm_head management from drm_connector_assign_connector_info() to drm_head_update_info()
The function drm_connector_assign_connector_info() should
not be calling functions to handle drm_head, as connectors
and heads are not the same thing after patch "drm-backend:
move connector data from struct drm_head to struct drm_connector".

Move drm_head specific calls to drm_head_update_info(). This
is more in line with the hierarchy of the objects and also
allow us to drop drm_head pointer from drm_connector.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2020-09-16 14:03:18 +00:00
Leandro Ribeiro
702fbf7282 drm-backend: cache drmModeObjectProperties for connectors
Instead of calling drmModeObjectGetProperties() each time that we need
the connector properties, it is better to keep a reference for it in
struct drm_connector. This reference is only updated when is necessary.
E.g. hotplug events.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2020-09-16 14:03:18 +00:00
Leandro Ribeiro
e636990de3 drm-backend: move connector data from struct drm_head to struct drm_connector
This is the first step in order to add support for writeback
connector in Weston. We don't want writeback connectors data
to be stored in 'struct drm_head' objects, as these objects are
used to output content and we should not use writeback connectors
for this purpose.

The writeback connectors will be stored in a new 'struct
drm_writeback', but the connector data is common between
'struct drm_head' and 'struct drm_writeback'.

So move connector data from 'struct drm_head' to 'struct
drm_connector'. This helps to avoid code duplication and makes
the code clearer.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2020-09-16 14:03:18 +00:00
Leandro Ribeiro
744c0cbb32 drm-backend: drop unused_crtcs from struct drm_backend
Now that we have a CRTC list in the DRM-backend, we can
iterate through it and look for the CRTCs that do not have
assigned outputs in order to find unused CRTCS.

So we can drop unused_crtcs from struct drm_backend and also
drop the functions drm_backend_update_unused_outputs() and
wl_array_remove_uint32().

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2020-09-07 13:04:06 -03:00
Leandro Ribeiro
b00d1a2efb drm-backend: move CRTC data from struct drm_output to new struct drm_crtc
There are no 'struct drm_output' for CRTCs that are not active.
Also, CRTC data lives in 'struct drm_output'. This is causing
us some trouble, as the DRM-backend needs to program those
unnactive CRTCs to be off.

If the DRM-backend had the reference for every CRTC (being
active or not), it would make certain functions (e.g.
drm_pending_state_apply_atomic()) more simple and efficient.

Move CRTC data from 'struct drm_output' to 'struct drm_crtc',
as this is the first step to allow the DRM-backend to have
references for every CRTC.

Also, add list of CRTCs to DRM-backend object. Now the
DRM-backend is responsible for allocating/deallocating the CRTC
objects. The outputs will only reference, init and fini the CRTCs
in this list.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2020-09-07 12:39:10 -03:00
Stefan Agner
465ab2cd92 backend-drm: allow to disable GBM modifiers
Allow to disable GBM modifiers at runtime using the environment variable
WESTON_DISABLE_GBM_MODIFIERS.

This can be useful for debugging or when modifiers cause issues, e.g. in
case modifiers use higher memory bandwidth and hence impose a lower
resolution limit as it is the case with Intel Kaby Lake graphics.

Related to: https://gitlab.freedesktop.org/wayland/weston/-/issues/404
Signed-off-by: Stefan Agner <stefan@agner.ch>
2020-08-17 10:17:30 +00:00
Alexandros Frantzis
9975134593 drm: Introduce drm_plane_reset_state() helper function
Introduce a helper function to reset the current state of a drm_plane.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
2020-08-17 09:44:45 +00:00
Michael Olbrich
3ac911f69b drm: remove duplicate function declarations
These functions are all declared twice in the same file. Remove on of the two
declarations.

Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
2020-08-06 10:22:18 +02:00
Scott Anderson
15c603caa6 drm: Fix leak of damage blob id
This moves the creation of the blob to be earlier, to when the damage is
calculated. It replaces the damage tracked inside of the plane state
with the blob id itself.

This should stop creating new blob ids for TEST_ONLY commits, and them
being leaked in general, as the blob ids are now freed with the plane
state.

The FB_DAMAGE_CLIPS property is now always set if it's supported, and
will be 0 in the case that we have no damage information, which
signifies full damage to the kernel.

Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
2020-06-04 09:52:16 +00:00
Lucas Stach
72e7a1ed48 backend-drm: Parse KMS panel orientation property, apply to weston_head
The KMS 'panel orientation' property allows the driver to statically
declare a fixed rotation of an output device. Now that weston_head has a
transform member, plumb the KMS property through to weston_head so the
compositor can make a smarter choice out of the box.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[daniels: Extracted from one of Lucas's patches]
Signed-off-by: Daniel Stone <daniels@collabora.com>
2020-03-06 21:50:38 +00:00
Emmanuel Gil Peyrot
1b3ad0993b backend-drm: Make boolean fields actually bool
Continues what dd8219b3fb started, also in
the DRM backend.
2019-12-11 19:33:20 +00:00
Emmanuel Gil Peyrot
b2f54d9f17 backend-drm: Remove unused variable
Its last usage was removed in 31838bf17e.
2019-12-11 19:33:20 +00:00
Stefan Agner
723c6a1266 backend-drm: Define potentially missing aspect-ratio bit definitions
The aspect ratio definitions for 64:27 and 256:135 have been added with
libdrm 2.4.95. However, Weston currently depends on libdrm 2.4.89 or
higher. Define the definitions in Weston to support libdrm older than
2.4.95.

Fixes: #332
Fixes: 6093772f45 ("backend-drm: Use aspect-ratio bit definitions from libdrm")
Signed-off-by: Stefan Agner <stefan@agner.ch>
2019-12-09 13:08:24 +00:00
Daniel Stone
6093772f45 backend-drm: Use aspect-ratio bit definitions from libdrm
When the aspect-ratio-aware mode support was added to Weston, it was
done before the libdrm support was finalised and merged. Between it
being added to Weston and being merged, it changed to no longer provide
the offset for the bitmask.

Instead of using the mask and a compatible enum, if we update our
libdrm dependency, we can use the flag definitions directly from libdrm.

In 94e4068ba1, the libdrm dependency was bumped to 2.4.83, which
enabled us to remove a bunch of error-prone ifdefs by making atomic and
modifier support mandatory.

We determined in the discussion of !311 that it was safe to push the
dependency as high as 2.4.91, as that was what was available in major
distributions.

Bumping to 2.4.86 allows us to safely remove the ifdef and go with
upstream flags, as that was added in mesa/drm@0d889201d1.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2019-11-27 17:52:16 +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
Marius Vlad
2538aaccc7 backend-drm: Construct a zpos candidate list of planes
In order to better optimize view assignment to HW planes, we construct
an intermediary zpos candidate list which is used aggregate all suitable
planes for handling scan-out capable client buffers.

We go over it twice: once to construct it and once to pick-and-choose a
suitable plane based its highest zpos position.

In order to maintain the view order correctly we track current zpos
value being applied to the plane state and use it when trying to place
a view into a plane.

Pass the computed zpos value to be applied to the plane state.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
2019-11-11 16:51:48 +00:00
Marius Vlad
3dea57a9d5 backend-drm: Add a helper to display plane type as a 'string'
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2019-11-11 16:51:48 +00:00
Marius Vlad
cdd6fa2717 backend-drm: Add zpos DRM-property
Functional no change, as nobody makes use of it. Only apply the zpos
value if the zpos property is mutable (that is, zpos_max and zpos_min
are not the same).

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2019-11-11 16:51:48 +00:00
Marius Vlad
1accffe053 backend-drm: Teach drm_property_info_populate() to retrieve range values
Useful for zpos range values.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
2019-11-11 16:51:48 +00:00
Daniel Stone
2cb926c558 Revert "backend-drm: Teach drm_property_info_populate() to retrieve range values"
Due to an error in driving GitLab, this commit erroneously contained the
entirety of !267 (zpos support in the KMS backend) squashed into one
single commit, pushed into master.

In order to keep the history clean, this is being reverted; a rebased
version of !267 with the clear individual commits which were already
present will be applied in its place.

This reverts commit 95e3b0deae.
2019-11-11 16:48:54 +00:00
Marius Vlad
95e3b0deae backend-drm: Teach drm_property_info_populate() to retrieve range values
Useful for zpos range values.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
2019-11-11 15:24:25 +00: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
Stefan Agner
3654c673f8 backend-drm: separate out DRM virtual support
Move DRM virtual support into a separate file. Use the remoting
compile time option to disable DRM virtual support since this is the
only user of DRM virtual support currently. This will make it easier
to build the DRM backend without GBM support.

Signed-off-by: Stefan Agner <stefan@agner.ch>
2019-10-25 15:32:07 +02:00
Ankit Nautiyal
a344fe3245 backend-drm: Add support for content-protection
Currently drm-layer supports HDCP1.4 using connector property:
Content Protection. This property if available for a platform, can be
read and set for requesting content-protection.
Also, the patch series [1] adds HDCP2.2 support in drm, and patch [2]
adds support to send udev events for change in connector properties,
made by the kernel.

This patch adds these HDCP connector properties in weston, and exposes
the content-protection support to the client for drm-backend.

It adds the enums to represent 'Content Protection' and 'Content Type'
connector properties exposed by drm layer. It adds a member
'protection' in drm_output_state, to store the desired protection
from the weston_output in the drm-backend output-repaint cycle. This
is then used to write the HDCP connector properties for the drm_heads
attached to the drm_output.

The kernel sends uevents to the user-space for any change made by it
in the "Content Protection" connector property. No event is sent in
case of change in the property made by the user-space.
It means, when there is a change of the property value from "DESIRED"
to "ENABLE" i.e. successful authentication by the kernel, a uevent
will be generated, but in case of userspace requesting for disabling
the protection by writing "UNDESIRED" into the property, no uevent
will be generated.

This patch also adds support for handling new udev events for HDCP
connector property changes. Any such change, triggers change in the
weston_head's current_protection.

[1] https://patchwork.freedesktop.org/series/57233/#rev7
[2] https://patchwork.freedesktop.org/patch/303903/?series=57233&rev=7

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2019-08-26 16:18:22 +05:30
Marius Vlad
c901e8913e weston-debug: Rename weston-debug to weston-log to better reflect its purpose
No changes in functionality have been made.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2019-07-18 10:49:39 +03:00