There are no internal users left for this protocol, they have been
migrated to the new weston-output-capture protocol. There are no
external users, because this protocol was private and never installed.
Remove this dead code.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is a completely new screenshooting protocol designed to support:
- color management testing by adding the "blending" source
- KMS testing by adding the "writeback" source
- output decorations testing by adding the "full_framebuffer" source
- proper buffer size negotiation instead of guessing from wl_output
- compositor chosen pixel format, primarily for "blending" source
- proper indication of screenshot failure
- dmabuf target buffers, linear only
This new protocol should be good enough to publish as a Weston public
extension. Hence install it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This protocol allows clients to create single-pixel RGBA buffers. Now
that we have proper support for these buffers internally within Weston,
we can expose them to clients.
This bumps the build container version, as we now depend on
wayland-protocols v1.26.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We want to support staging protocols which have a version too, so don't
assume that anything versioned is unstable.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This allows easily co-developing a Wayland protocol and Weston.
Example setup:
ln -s subprojects/wayland-protocols /path/to/wayland-protocols
meson configure build/ --force-fallback-for=wayland-protocols
Signed-off-by: Simon Ser <contact@emersion.fr>
Bump the wayland-protocol dependency version in order to include dma-buf
feedback, whose support in Weston is added in the next commits.
Also, as we need the newer EGL extension EGL_EXT_device_drm_render_node
to add the support for dma-buf feedback, bump the Mesa dependency
version as well.
It also includes some minor changes in order to keep build-deps.sh more
consistent.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
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>
Pekka Paalanen