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>
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@0d889201d106.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Remove unnecessary ifdefs for DRM_MODE_CONNECTOR_DSI, DRM_MODE_CONNECTOR_DPI.
They are both provided by libdrm and were introduced long before 2.4.83 (the
lowest version we currently support).
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
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>
Mode change from mixed-mode to renderer-only means we should no longer
try to place views in HW planes (as we composite everything into the
primary plane) thus we should avoid that whenever that happens.
In the same time we need to be able to place in mixed-mode/renderer-only
mode the cursor view into the cursor plane (if one is available).
This patch adds a further check to skip plane assignment when disabling
overlay support (when we switch to renderer-only mode), when drivers do
not have atomic-modeset or it has been disabled intentionally.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Adds a further assert() to make sure we're not checking against invalid
values. This was seen in the wild when the kernel rejects the commit for
overlay resulting in a check for invalid zpos values.
Fixes: #304
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
when switching to mixed-mode of compositing
This way we avoid an (incorrect) duplicate check of zpos values. Also,
this would be needed because the renderer needs have the lowest zpos value
available as we don't (yet) properly support underlays, the primary
plane serves as our renderer.
Adds also a check to see if we try to assign a view to a plane with
a lower zpos value than the one assigned to the primary when switching
to mixed-mode of compositing.
Fixes: #304
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
It makes much more sense to be there. It adds some additional drm_debug()
statements to provide reason for failing to place the view in the HW
plane. Makes the reason for failing more accurate.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Avoids the need to retrieve the DRM framebuffer in each function and
re-uses the one got before constructing the zpos candidate list.
Takes another reference for the scanout as to live the state, like
there's one for the overlay bit.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As we already have a potential plane available to use, pass it
over the _prepare_overlay_view instead of trying to find one
from the backend plane list.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
In this manner we will allow views to reach the overlay (or underlays)
even if the damage tracking will detect that the new view will
occlude the view underneath it.
Renames occluded_region to planes_region, and uses occluded_region
to represent the region where we add each view's visible-and-opaque region.
Sprinkle some comments about each region.
Re-uses the view's clipped region to determine visible-and-opaque region
which is accumulated (for both renderer and HW planes cases) into
occluded_region. The current view's clipped_region is then checked against
occluded_region.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
We can determine if the pixel format used by the clients buffer is
scan-out capable much sooner, so do it when constructing the zpos
candidate list. It also removes the checks in their respective
prepare_ functions.
Avoids the situation where we'd need to retrieve the DRM framebuffer each time
when checking the pixel format.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
function
The idea is to place pixel the format checks in a common part and until
then, to make it available as a function so we can re-use easily.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
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>
This is based on the assumption that overlays are in between cursor and
primary plane and it is required to be able to assign views to planes,
even if the driver doesn't not expose such property.
As we hard-code them as immutable the commit part would not need any
further modifications.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
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>
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.
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>
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>
In the future libweston will stop providing it for its users, since it's not
part of libweston API.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We have two kinds of libweston users: internal and external. Weston, the
frontend, counts as an external user, and should not have access to libweston
private headers. The shell plugins are external users as well, because we
intend people to be able to write them. Renderers, backends, and some plugins
are internal users who will need access to private headers.
Create two different Meson dependency objects, one for each kind.
This makes it less likely to accidentally use a private header.
Screen-share is a Weston plugin and therefore counts as an external user, but
it needs the backend API to deliver input. Until we are comfortable exposing
public API for that purpose, let it use internal headers.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
As 'new_subscription' can create additional objects, 'destroy_subscription'
will be needed when cleaning up.
As this requires a libweston_major bump (noticed by @pq), bump it up to
8.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
In case the base EGLConfig is needed, gl_renderer_display_create() needs to
know it should use EGL_WINDOW_BIT or EGL_PBUFFER_BIT.
The PBUFFER case is added for when the headless backend will grow GL-renderer
support.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Define common_inc which includes both public_inc and the project root directory.
The project root directory will allow access to config.h and all the shared/
headers.
Replacing all custom '.', '..', '../..', '../shared' etc. include paths with
common_inc reduces clutter in the target definitions and enforces the common
#include directive style, as e.g. including shared/ headers without the
subdirectory name no longer works.
Unfortunately this does not prevent one from using private libweston headers
with the usual include pattern for public headers.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When all shared/ headers are included in the same way, we can drop unnecessary
include seach paths from the compiler.
This include style was chosen because it is prevalent in the code base. Doing
anything different would have been a bigger patch.
This also means that we need to keep the project root directory in the include
search path, which means that one could accidentally include private headers
with
#include "libweston/dbus.h"
or even
#include <libweston/dbus.h>
IMO such problem is smaller than the churn caused by any of the alternatives,
and we should be able to catch those in review. We might even be able to catch
those with grep in CI if necessary.
The "bad" include style was found with:
$ for h in shared/*.h; do git grep -F $(basename $h); done | grep -vF '"shared/'
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that all backends pass in a list of acceptable DRM formats, that is used to
determine if the EGLConfig has an alpha channel or not. Therefore the
opaque_attribs and alpha_attribs are now useless, and we can remove the whole
config_attribs argument from the API.
gl_renderer_get_egl_config() uses an internal attrib list that matches at least
the union of the opaque_attribs and alpha_attribs matches.
Overall, behaviour should remain unchanged.
The new attribute array becomes variable in the future, so it is left
non-const.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Replace a direct call to egl_choose_config() with a higher level function
gl_renderer_get_egl_config(). This will make follow-up work easier when
attribute lists will be generated inside gl_renderer_get_egl_config() instead
of passed in as is.
We explicitly replace visual_id with drm_formats, because that is what they
really are. Only the DRM backend passes in other than NULL/0, and if other
backends start caring about the actual pixel format, drm_format is the lingua
franca.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In an attempt to pull more of EGLConfig choosing into one place, refactor code
into the new gl_renderer_get_egl_config(). The purpose of this function is to
find an EGL config that not only satisfies the requested attributes and the
pixel formats if given but also makes sure the config is generally compatible
with the single GL context we have.
All this was already checked in gl_renderer_create_window_surface(), but
gl_renderer_create_pbuffer_surface() is still missing it. This patch is
preparation for fixing the pbuffer path.
We explicitly replace visual_id with drm_formats, because that is what they
really are. Only the DRM backend passes in other than NULL/0, and if other
backends start caring about the actual pixel format, drm_format is the lingua
franca.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Replace one more open-coded pixel format translation map with a call to our
central pixel format database, reducing duplication of format information.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
No caller ever used anything but NULL here, so just use NULL to simplify code.
In fact, no EGL platform defined today even defines any platform attributes
except the X11 platform for choosing a non-default SCREEN.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
The member disable_planes of weston_output signifies the recording
status of the output, and is incremented and decremented from various
places. This patch provides helper functions to increment and decrement
the counter. These functions can then be used to do processing, before
and after the recording has started or stopped.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
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>
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")
Emmanuel Gil Peyrot
Stefan Agner
Daniel Stone
Leandro Ribeiro
Marius Vlad
Nicholas Niro
Marius Vlad
Pekka Paalanen
Ankit Nautiyal