There is missing dependency on linux-dmabuf-unstable-v1-server-protocol.h
header file in backend-headless, backend-drm and backend-x11. That files
do not depend on that header, in fact. But by this moment they've had
that implicit dependency due to linux-dmabuf.h header.
With specific set of meson configure options the protocol header is not
generated at the right time, what causes build error in 100% cases using
small amount of building threads (from -j1 to -j8).
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>
This is a 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>
This uses the legacy DRM API it incomplete and no longer works anyways.
At this point, weston is no longer DRM master, so these calls fail with
"Permission denied".
So just remove the corresponding code.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
If a surface or a view is not mapped, then we should not be trying to
paint it. Check if this is the case and ensure that we only insert
paint nodes for mapped surfaces & views.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: #621
Now we've got a wrapper which tells us whether or not the surface has
valid content, use it.
The 'XXX' comment was removed because it's the same pattern as every
other surface-role implementor: if the surface is not mapped but does
have valid content, then map it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
"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>
Add a struct weston_head parameter to weston_compositor_create_output()
and fold weston_compositor_create_output_with_head() into it.
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
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>
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>
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>
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>
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>
Stop plugins from overwriting the struct weston_output::destroy vfunc,
as that will be used by backends to recognize their outputs.
Instead, pass a plugin-specific destroy callback when creating the
virtual output.
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The get file descriptor functions are being deprecated and a two step
process of getting handles and then getting the descriptors for the
handles is being used instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Update to a newer FreeRDP release so we can start cleaning up
some of our usage of things that will be deprecated in the next
major release.
For this, I've simply picked the newest version currently in
our CI images.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This reverts commit 6914064066.
This is a follow-up change of b623fd2a ("drm-backend: stop parsing IN_FORMATS
blobs, use libdrm instead"). Weston now has a hard-requirement on libdrm
2.4.108, clean up remaining and unnecessary conditional code. Change 69140640
("backend-drm: add HDR_OUTPUT_METADATA definitions") is no longer needed
and stop including libdrm-updates.h from kms-color.c.
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
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>
This patch makes sure we have a gl_buffer_state present when using
direct-display protocol extensions (which forbids any GL imports, and
assumes a direct path with the display unit to perform a KMS import).
Without this patch we would basically have no gl_buffer_state at repaint
time because we never manged to create one, as direct-display code path
will return much early.
Partially fixes gitlab.freedesktop.org/wayland/weston/-/issues/621.
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
It's bad form to set the same variable in multiple places, and not all
of them were even equivalent.
Move lcms2 finding to the root level build file only. It is still an
optional dependency like before, and the if-not-found checks are still
in place where actually needed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When color management is disabled, the fragment shader was still first
ensuring straight alpha and then immediately just going back to
pre-multiplied. This is near-impossible for a shader compiler to
optimize out, I guess because of the if-statement to handle division by
zero. Having view alpha applied in between certainly didn't make it
easier.
That causes extra fragment computations that are unnecessary. In the
issue report this was found to cause a notable performance regression.
Fix the performance regression by introducing special-case paths for
when straight alpha is not needed. This skips the unnecessary
computations.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/623
Fixes: 9a6a4e7032
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Currently, the opaque is discarded for all transformations other than a simple
translation, because correctly transforming the opaque area is not possible in
general.
However, there is one simple case that is probably the most common one: A fully
opaque surface that is translated and scaled. In this case the opaque area is
simply the new bounding box. So set the transformed opaque area accordingly.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
If surface->is_opaque is set then we can assume that the whole surface is
opaque. In the trivial case (no transformation or translation only) this means
that transform.boundingbox is exactly the view area and is fully opaque. So it
can be used for transform.opaque.
This is important because damage calculation uses transform.opaque. Without
this, anything underneath a surface without an explicit opaque region but a
pixel format without alpha channel is drawn unnecessarily.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
The drm_device is initialized as a side effect of the (badly named)
drm_device_is_kms function. Explicitly pass the drm_device to be able to
initialize kms devices that are not the main drm device of the drm backend.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
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>
If Weston receives a hotplug event, it has to check if the hotplug device
actually belongs to the drm device before updating the heads of the device. The
hotplug event should only remove heads that belong to the device and must not
change heads of other devices.
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 scanout format for the dma-buf feedback are specific to the kms device that
is used for scanout. Therefore, we have to pass the device of the output when
retrieving the scanout formats.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
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>
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>
The gbm_format is the same as the drm format used by the pixel format.
Print the format name using the pixel format in the error message to make the
error message easier to understand for humans.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The fb already contains a DRM fd for later use. So just use that one instead of
fetching it from the backend.
This is necessary if the fbs are allocated on different devices, since otherwise
the wrong device might be used to get the fd of the passed fb.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
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>
The RDP spec says we can trust x, y position on all messages except
PTR_FLAGS_WHEEL and PTR_FLAGS_HWHEEL, so let's do that to ensure
proper sync with the RDP client.
Co-authored-by: Steve Pronovost <spronovo@microsoft.com>
Co-authored-by: Brenton DeGeer <brdegeer@microsoft.com>
Signed-off-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Steve Pronovost <spronovo@microsoft.com>
Signed-off-by: Brenton DeGeer <brdegeer@microsoft.com>
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>
Obviously the first allocation is always leaked, there is a second
zalloc() right below. Fix the leak.
Found by code inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
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>
Forward the HDR Static Metadata Type 1 to the video sink. This makes the
sink aware of our video content parameters and may be able to produce a
better picture. This type of metadata is used only with the ST 2084 HDR
mode a.k.a PQ.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
'color_characteristics_config_error' test ensures that all code paths in
parse_color_characteristics() and wet_output_set_color_characteristics()
get exercised. The return value and logged error messages are checked.
Other cases test the weston_hdr_metadata_type1 validation.
These are for the sake of test coverage, but also an example of how to
test a function from main.c, and how to capture messages from
weston_log().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the beginnings of creating composited content HDR metadata for
the ST2084 HDR mode. The immediate goal is to allow essentially setting
the HDR metadata from weston.ini, so that it can be experimented with.
Setting an output ICC profile will stop weston.ini metadata from taking
effect, but using an ICC profile in HDR mode is an open question anyway.
maxDML, maxCLL, and minDML are set based on the assumption that we want
to make use of the full sink/monitor dynamic range.
This also adds several TODOs about how we should handle output profiles,
basic output color characteristics, and HDR metadata. Implementing these
properly will take more thought and effort.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds hdr_meta field in weston_output_color_outcome. This field is
intended to be set by color manager modules, and read by backends which
will send the information to the video sink in SMPTE ST 2084 mode a.k.a
Perceptual Quantizer HDR system.
Such metadata is essential in ST 2084 mode for the video sink to produce
a good picture.
The validation of the data and the group split is based on the HDR
Static Metata Type 1 definition in CTA-861-G specification.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
