Commit Graph

43 Commits

Author SHA1 Message Date
vanfanel
3240ccc69d Don't change the max_bpc connector prop if mode=current.
As things are, even when mode=current is specified on the .ini file,
a full modeset is needed (and done), which causes a very noticeable
screen blinking. That is because setting the max_bpc on a connector
needs full modesetting.
The idea here is that if mode=current on the .ini, no modesetting
should be done, so the current max_bpc is programmed into the
connector.
But if a custom max-bpc=... is specified, that will be used instead,
even if mode=current on the .ini

Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/660

Signed-off-by: vanfanel <redwindwanderer@gmail.com>
2022-09-23 11:05:34 +00:00
Michael Olbrich
2929b6c483 backend-drm: check that outputs are in fact ours
This is another followup to ffc011d6a3
("backend-drm: check that outputs and heads are in fact ours") which missed
some places.

Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
2022-06-23 14:00:04 +00:00
Pekka Paalanen
d24adbbe25 backend-drm: set connector max bpc
"max bpc" property is meant for working around faulty sink hardware.
Normally it should be set to the maximum possible value so that the
kernel driver has full freedom to choose the link bpc without being
artificially forced to lower color precision.

The default value is 16 because that is a nice round number and more
than any link technology I've heard is using today which would be 12.

Also offer an API set the value, so that weston.ini could be used in the
next patch for sink workaround purposes.

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

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2022-06-15 12:58:38 +00:00
Philipp Zabel
ffc011d6a3 backend-drm: check that outputs and heads are in fact ours
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>
2022-06-10 09:27:43 +00:00
Luigi Santivetti
a62bf5ff48 drm-backend: stop parsing IN_FORMATS blobs, use libdrm instead
Before this change the drm-backend in Weston did the work of parsing DRM
blobs in order to query IN_FORMATS data, if available. This is also the
case for other DRM/KMS clients that use IN_FORMATS (i.e. X).

libdrm 2.4.108 with e641e2a6 ("xf86drm: add iterator API for DRM/KMS
IN_FORMATS blobs") introduced a dedicated API for querying IN_FORMATS data.

Bump the minimum required version to 2.4.108, stop parsing IN_FORMATS in
Weston and start using DRM iterators. In addition, remove fallback code for
libdrm <2.4.107.

Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
2022-06-07 09:35:14 +01:00
Michael Tretter
deebfd99e3 backend-drm: get the drm device from the output
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>
2022-06-03 09:17:49 +02:00
Michael Tretter
d990c6a939 backend-drm: ignore heads from other devices
The compositor lists the heads from all devices, but we must only disable the
connectors that belong to the current device. Therefore, other heads must be
ignored.

Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
2022-06-03 09:17:16 +02:00
Michael Tretter
345e705e33 backend-drm: move drm objects from backend to drm device
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>
2022-06-03 09:17:15 +02:00
Michael Tretter
c4685d9463 backend-drm: attach device to pending state
The commits happen per device instead of per backend. The pending state is
therefore per device as well. Allow to retrieve the device from the pending
state.

Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
2022-06-03 09:14:11 +02:00
Michael Tretter
d89fcf10cb backend-drm: pass device through atomic commit handler
The atomic commit is device specific. If we have multiple kms devices, we need
to know which device was used for the atomic commit.

Pass the device instead of the backend through the atomic commit.

Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
2022-06-03 09:13:23 +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
Michael Tretter
2860933ded backend-drm: cleanup debugging
Get the backend at the beginning of the function instead of retrieving it from
another object in the debug statement. This simplifies refactoring, as the debug
statement is not affected by changes how the backend is retrieved.

Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
2022-06-03 09:04:29 +02: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
nerdopolis
d2a320d53e Fix TTY switching after failed failed repaint with legacy mode set.
Reported in !179 adding weston_output_repaint_failed resets the output

Co-authored-by: Daniel Stone
Co-authored-by: Julius Krah
Signed-off-by: n3rdopolis <bluescreen_avenger@verizon.net>
2021-09-29 12:17:58 +00: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
Pekka Paalanen
f48277b577 drm-backend: require DRM_CAP_TIMESTAMP_MONOTONIC
Weston internals and Wayland clients assume that output presentation
clock cannot go backwards. Therefore require unconditionally that KMS
uses the monotonic clock.

The kernel unconditionally supports DRM_CAP_TIMESTAMP_MONOTONIC. See:

commit 25e1a79874eb3821d93310c908cc0a81b47af060
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Oct 11 17:20:13 2017 +0200

    drm: vblank: remove drm_timestamp_monotonic parameter

That one removed the final possibility of DRM_CAP_TIMESTAMP_MONOTONIC
being false, by removing the module option. But even before that, all
drivers have been supporting monotonic, since

commit c61eef726a78ae77b6ce223d01ea2130f465fe5c
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Oct 23 18:53:26 2012 +0000

    drm: add support for monotonic vblank timestamps

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-05-11 09:07:46 +00:00
Leandro Ribeiro
98101e88cc backend-drm: ignore formats without modifiers from IN_FORMATS
In commit "backend-drm: add DRM_FORMAT_MOD_INVALID to modifier sets when
no modifiers are supported" we've changed the code that iterates through
the IN_FORMATS blob property. Now it adds DRM_FORMAT_MOD_INVALID for
formats exposed without modifiers.

But the thing is that there shouldn't be formats in the IN_FORMATS blob
exposed without modifiers, as the blob has been added after the
introduction of the explicit modifiers API in the kernel. For now,
there's nothing in the kernel to ensure this correct behavior. So
instead of adding DRM_FORMAT_MOD_INVALID in this case, ignore these
formats, as userspace can't do much in this case.

In the future this may be fixed by the kernel. Or maybe the following MR
in libdrm, which adds an iterator API for the IN_FORMATS blob:

https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/146

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2021-04-27 19:56:38 +00:00
Leandro Ribeiro
567cc92797 backend-drm: add DRM_FORMAT_MOD_INVALID to modifier sets when no modifiers are supported
From now on, when we can't know the modifiers supported for a certain
format, we add DRM_FORMAT_MOD_INVALID to its modifier set.

There is some parts where nothing is being added an others where
DRM_FORMAT_MOD_LINEAR is being added, so fix them.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2021-04-27 19:56:38 +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
Pekka Paalanen
b9ca801324 drop MOD_INVALID, MOD_LINEAR definitions
MOD_INVALID came with libdrm 2.4.83 and MOD_LINEAR came with libdrm
2.4.82. libweston unconditionally depends on libdrm >= 2.4.95, so the
fallback is not necessary.

Since linux-dmabuf.h itself has no use for these and also forgets to
include drm_fourcc.h, .c files including drm_fourcc.h after this header
would trigger compiler warnings.

linux-dmabuf.c does need these, so add the proper include.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-02-25 14:35:03 +02: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
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
Leandro Ribeiro
ea4d13b3e3 drm-backend: remove log that advertises universal planes support
There's a log that advertises support for universal planes. That
can make users think there's something wrong with Weston or their
systems when universal planes are not supported, but that's not
the case. Remove this log from the code.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
2020-07-28 11:13:53 -03: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
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
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
Ankit Nautiyal
fc2c180926 backend-drm: Check for HDCP Content Type property before setting
Currently, a check is missing for the case if the HDCP Content Type
property is requested, but is not supported by the driver.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2019-08-30 19:46:04 +05:30
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
Stefan Agner
974390a5fa backend-drm: get handle in gbm specific code
Get GBM BO handle in GBM specific code. This allows to compile
drm_output_set_cursor without GBM.

Signed-off-by: Stefan Agner <stefan@agner.ch>
2019-07-08 23:53:30 +02: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
Tomohito Esaki
29beeafde9 backend-drm: make linear modifier to default
Make the linear modifier to the default of DRM format modifiers if
supported modifiers isn't get from kernel driver.
2019-07-01 10:57:25 +09:00
Daniel Stone
4c2fc7058a compositor-drm: Move KMS API use to separate file
Create a new file which handles most of the actual KMS API use. This
covers the property handling (in which we map between KMS properties and
our internal representations), as well as actually applying state
through atomic modesetting or the legacy SetCrtc/PageFlip/DPMS APIs.

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