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>
The drm_color_encoding and drm_color_range enums are used for
YUV->RGB conversion and mirror what EGL_YUV_COLOR_SPACE_HINT_EXT
and EGL_SAMPLE_RANGE_HINT_EXT as well as our `yuva2rgba()`
shader func do. Add the necessary boiler plate for them.
Signed-off-by: Robert Mader <robert.mader@collabora.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>
Since DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP capability is available in the
mainline kernel, now we should enable back tearing support.
v2:
- Bump kernel version to 6.9
- include the fallback definitions
Reviewed-by: Marius Vlad <marius.vlad@collabora.com>
Reviewed-by: Derek Foreman <derek.foreman@collabora.com>
Signed-off-by: Naveen Kumar <naveen1.kumar@intel.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>
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>
Let backends declare the presentation clocks they can use with a
new bitfield weston_backend::supported_presentation_clocks and set
presentation clock after loading the backend in the compositor.
Make weston_compositor_set_presentation_clock() internal and replace
weston_compositor_set_presentation_clock_software() with an exported
weston_compositor_backends_loaded(), which is called by the compositor
after the backend is loaded.
In the future, this can be extended to determine the subset of clocks
supported by all backends.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Until kernel mainline does merge the aysnc page flip ioctl, make the
whole bit look like it's unsupported. We can further switch it back when
it lands into the kernel.
Fixes: 9203d98f
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Simon Ser <contact@emersion.fr>
Remove plane->damage and instead accumulate damage on paint
nodes.
This is a step towards allowing multiple overlapping outputs.
Signed-off-by: Derek Foreman <derek.foreman@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>
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>
With multiple DRM devices, the state for one device may be empty during
repaint_flush(). This can happen for example if an output of one device triggers
the repaint and there are no screens attached to the other device and therefore
no active outputs.
The atomic commit will actually fail because the commit contains the
DRM_MODE_PAGE_FLIP_EVENT flag but no CRTCs.
Avoid this by skipping the commit entirly. There is nothing to to anyways.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
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>
From our perspective, a bitmask is pretty much the same as an enum, so
allow it to use the same path.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We are assuming that CRTC_CTM is pass-through, so better ensure it
really is pass-through rather than whatever the previous KMS client left
there.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We are assuming that CRTC_DEGAMMA_LUT is pass-through, so better ensure
it really is pass-through rather than whatever the previous KMS client
left there.
This too falls under deprecated_gamma_is_set check, because the legacy
gamma could use either GAMMA or DEGAMMA.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We are assuming that gamma LUT is pass-through, so better ensure it
really is pass-through rather than whatever the previous KMS client left
there.
Unfortunately the legacy ioctl does not offer any way to reset the LUT
without actually crafting an identity LUT.
If the legacy gamma libdrm function indicates the feature is not
supported, do not try to use it again. This avoids hammering the legacy
gamma every frame when deprecated drm_output_set_gamma() is not used.
drm_output_set_gamma() is not updated to check/set this flag in order to
maintain its old behavior.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We are assuming that CRTC_GAMMA_LUT is pass-through, so better ensure it
really is pass-through rather than whatever the previous KMS client left
there.
Unfortunately, we have old drm_output_set_gamma() API that cms-static
and cms-colord plugins are using. To avoid trampling over them, do not
touch gamma after they did. Those plugins are deprecated, so there is no
reason to make set_gamma work through atomic.
drm_output_set_gamma() is called from weston_compositor_add_output()
through the output_created_signal. This is after drm_output_enable() and
before any KMS modeset or atomic commit on the CRTC. Therefore it is not
possible that there would be any KMS action in flight when
drm_output_set_gamma() is called, and so setting deprecated_gamma_is_set
should be non-racy - like setting CRTC_GAMMA_LUT itself.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Move the debug printing before the bail-out if the property does not
exist. This means that trying to set a missing property will be logged,
and it can be identified by the property id being 0.
We are starting to program more KMS properties, and if KMS state
building fails, this gives better chances to figure out what happened.
For example, if we accidentally assume that some property always exists
when it doesn't.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that the renderer type is stored in struct weston_renderer,
use that instead of use_pixman to determine the renderer type.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Some monitors expose a selector for the kind of content that will get
displayed, allowing them to optimise their settings for this particular
content type.
I got access to such a monitor, sadly even setting it to game mode
didn’t lower its atrocious latency, but drm_info[1] reports it to be set
correctly so hopefully it’ll work better with other monitors.
[1] https://github.com/ascent12/drm_info
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
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>
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>
"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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
