Because we weren't properly pinning the wayland-protocols version, and I
can't read, we missed updating this in !563.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Weston extension to assure clients that the dmabuf buffer will be
forwarded directly to the display controller.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This protocol allows a client to ask the compositor to only allow it to
be displayed on a "secure" output. This initial version of the protocol
supports HDCP.
This is loosely based on the chromium secure-output protocol [1].
This protocol is mostly useful for closed system, where the client can
trust the compositor, such as set-top boxes. This is not a way to
implement any kind of Digital Rights Management on desktops. The
compositor would be free to lie to the client, anyway.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
[1]
https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
Some clients like the mpv video player now request the xdg_shell
protocol so these will fail if the compositor only provides the
xdg_shell_unstable_v6 protocol. Compositors like mir and gnome provide
both protocols.
The two protocols are very similar therefore the code in xdg-shell-v6.c
has been refactored to work with the new xdg_shell protocol and now
resides in xdg-shell.c.
Pekka:
- split the patch
- fix continued line alignment
Daniel
- allow anchor_rect to initially have zero dimensions
- account for get_popup allowing NULL parent surface
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Introduce support for the zwp_linux_explicit_synchronization_unstable_v1
protocol with an implementation of the zwp_linux_explicit_synchronization_v1
interface.
Explicit synchronization provides a more versatile notification
mechanism for buffer readiness and availability, and can be used to
improve efficiency by integrating with related functionality in display
and graphics APIs.
In addition, the per-commit nature of the release events provided by
this protocol potentially offers a solution to a deficiency of the
wl_buffer.release event (see
https://gitlab.freedesktop.org/wayland/wayland/issues/46).
Support for this protocol depends on the capabilities of the backend, so
we don't register it by default but provide a function which each
backend will need to call. In this commit only the headless backend when
using the noop renderer supports this to enable testing.
Note that the zwp_surface_synchronization_v1 interface, which contains
the core functionality of the protocol, is not implemented in this
commit. Support for it will be added in future commits.
Changes in v7:
- Added some information in the commit message about the benefits of
the explicit sync protocol.
Changes in v6:
- Fall back to advertising minor version 1 of the explicit sync protocol,
although we support minor version 2 features, until the new
wayland-protocols version is released.
Changes in v5:
- Meson support.
- Advertise minor version 2 of the explicit sync protocol.
Changes in v4:
- Enable explicit sync support in the headless backend for all
renderers.
Changes in v3:
- Use wl_resource_get_version() instead of hardcoding version 1.
- Use updated protocol interface names.
- Use correct format specifier for resource id.
- Change test name to 'linux-explicit-synchronization.weston'
(s/_/-/g).
Changes in v2:
- Move implementation to separate file so protocol can be registered
on demand by backends.
- Register protocol in headless+noop backend for testing purposes.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Meson is a build system, currently implemented in Python, with multiple
output backends, including Ninja and Make. The build file syntax is
clean and easy to read unlike autotools. In practise, configuring and
building with Meson and Ninja has been observed to be much faster than
with autotools. Also cross-building support is excellent.
More information at http://mesonbuild.com
Since moving to Meson requires some changes from users in any case, we
took this opportunity to revamp build options. Most of the build options
still exist, some have changed names or more, and a few have been
dropped. The option to choose the Cairo flavour is not implemented since
for the longest time the Cairo image backend has been the only
recommended one.
This Meson build should be fully functional and it installs everything
an all-enabled autotools build does. Installed pkg-config files have
some minor differences that should be insignificant. Building of some
developer documentation that was never installed with autotools is
missing.
It is expected that the autotools build system will be removed soon
after the next Weston release.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Co-authored-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Daniel Stone
Marius Vlad
Jonas Ådahl
Scott Anderson
ant8me
Alexandros Frantzis