Debian Jessie's version of libxkbcommon is too old for compose support,
so rather than force people to upgrade, let's make it conditional.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Díaz <daniel.diaz@linaro.org>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
This patch implements additional functionality that will be used
for configuring, enabling and disabling weston's outputs. Its
indended use is by the compositors or user programs that want to
be able to configure, enable or disable an output at any time. An
output can only be configured while it's disabled.
The compositor and backend specific functionality is required
for these functions to be useful, and those will come later in
this series.
All the new functions have been documented, so I'll avoid
describing them here.
v2:
- Minor documentation improvements.
- Rename output-initialized to output->enabled.
- Split weston_output_disable() further into
weston_compositor_remove_output().
- Rename weston_output_deinit() to weston_output_enable_undo().
- Make weston_output_disable() call two functions mentioned
above instead of calling weston_output_disable() directly.
This means that backend needs to take care of doing backend
specific disable in backend specific destroy function.
v3:
- Require output->name to be set before calling
weston_output_init_pending().
- Require output->destroying to be set before
calling weston_compositor_remove_output().
- Split weston_output_init_pending() into
weston_compositor_add_pending_output() so pending outputs
can be announced separately.
- Require output->disable() to be set in order for
weston_output_disable() to be usable.
- Fix output removing regression that happened when
weston_output_disable() was split.
- Minor documentation fix.
v4:
- Bump libweston version to 2 as this patch breaks the ABI.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Armin Krezović <krezovic.armin@gmail.com>
Check that the defined versions for Weston and libweston are consistent
and according to the version bumping rules:
- In pre-release and only pre-release versions the weston and libweston
may differ
- when they differ, libweston version must be exactly (weston.major+1).0.0
- otherwise, the versions must be exactly the same.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This bump is required for the following patch that adds strict version
consistency checking between weston and libweston.
This bumps libweston major from 0 to 1. All libweston users need to
adapt. This major bump would have to be made on the 1.11.91 release
anyway.
Cc: Giulio Camuffo <giuliocamuffo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
libweston-desktop is an abstraction library for compositors wanting to
support desktop-like shells.
The API is designed from xdg_shell features, as it will eventually be
the recommended shell for modern applications to use.
In the future, adding new shell protocols support will be easier, as
limited to libweston-desktop.
The library versioning is the same as libweston. If one of them break
ABI compatibility, the other will too.
The compositor will only ever see toplevel surfaces (“windows”), with
all the other being internal implementation details.
Thus, popups and associated grabs are handled entirely in
libweston-desktop.
Xwayland special surfaces (override-redirect) are special-cased to a
dedicated layer, as the compositor should not know about them.
All the shell error checking is taken care of too, as well as some
specification rules (e.g. sizes constraint for maximized and fullscreen
surfaces).
All the compositor has to do is define a few callbacks in the interface
struct, and manage toplevel surfaces.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Giulio Camuffo <giulio.camuffo@kdab.com>
Differential Revision: https://phabricator.freedesktop.org/D1207
Use the documented libweston-$major.so.0.$minor.$patch scheme.
An (almost) identical one is used by GLIB, GDK{2,3}, QT5, json-glib and
others.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
We are growing more tests that need to handle buffers, both just images
and wl_buffers. Particularly the screenshooting facility needs these.
Currently everything is in struct surface, which contains more than we
need. It is a bit messy.
Create a new struct buffer to encapsulate the image representation, the
wl_buffer, and enough information to tear it all down (munmap) so we
don't have to leak everything. Some tests might start doing things in
loops, and leaking would accumulate.
Instead of inventing our own image representation, use pixman_image_t.
It is a well-tested library worth using, and we already rely on it in
other places.
This makes the tests depend on Pixman, which requires the fix for
building buffer-count, which would otherwise not find pixman.h.
The new create_shm_buffer_a8r8g8b8() creates an image with an explicit
format, and pixman_image_t keeps track of it. And stride and size and
data. This implementation is still a little hacky due to calling
create_shm_buffer().
A very new thing is buffer_destroy(). Previously we didn't really free
any buffers. It is not a problem when the process will exit soon anyway,
but it may become a problem if tests start iterating things.
Manual memset() on a image is converted to a pixman action, just to show
how to do it properly with pixman.
Stride and pixel format assumptions still linger all around, but those
are for another patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This clarifies what is supposed to be the libweston code.
v2: screen-share.c is already in compositor/ instead.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Acked-by: Benoit Gschwind <gschwind@gnu-log.net>
[Pekka: rebased]
This is the start of separating weston-the-compositor source files from
libweston source files.
This is moving all the files related to the 'weston' binary. Also the
CMS and systemd plugins are moved.
xwayland plugin is not moved, because it will be turned into a
libweston feature.
To avoid breaking the build, #includes for weston.h are fixed to use
compositor/weston.h. This serves as a reminder that such files may need
further attention: moving to the right directory, or maybe using the
proper -I flags instead.
v2: Move also screen-share.c, and add a note about weston-launch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Acked-by: Benoit Gschwind <gschwind@gnu-log.net>
[Pekka: rebased]
Pixman's headers include a representation of -1 in fixed-point, which is
-1 << 16. This trips a GCC warning about shifting negative values. As we
can't do much about it, just silence the warning.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
This was a left-over from ca52b31d3f.
Reported-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Migrate from wl_scaler to wp_viewporter extension. The viewporter.xml
file is provided by wayland-protocols.
This stops Weston from advertising wl_scaler, and advertises
wp_viewporter instead.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
[Pekka: fix wayland-protocols requirement]
This commit also adds a libweston-0.pc file. The -0 is the abi version
introduced in the previous patch.
Signed-off-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The backends are now installed in lib/libweston-0, and the include
files that will be used by libweston in include/libweston-0. The other
modules and weston-specific include files are kept in the old paths.
A new wet_load_module() is added to load plugins in the old path,
which is not part of libweston, but weston only and defined in main.c.
To allow that to be used by out of tree weston plugins, the function
is declared in a new weston.h, installed in include/weston.
The -0 in the paths is the abi version of libweston, and it will also
be used by the libweston .so. If the abi changes the number will need
to be increased.
Signed-off-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This patch completely removes the Raspberry Pi backend and the renderer.
The backend and the renderer were written to use the proprietary
DispmanX API available only on the Raspberry Pi, to demonstrate what the
tiny computer is capable of graphics wise. They were also used to
demonstrate how Wayland and Weston in particular could leverage hardware
compositing capabilities that are not OpenGL. The backend was first
added in e8de35c922, in 2012.
Since then, the major point has been proven. Over time, support for the
rpi-backend diminished, it started to deteriorate and hinder Weston
development. On May 11, I tried to ask if anyone actually cared about
the rpi-backend, but did not get any votes for keeping it:
https://lists.freedesktop.org/archives/wayland-devel/2016-May/028764.html
The rpi-backend is a good example of how using an API that is only
available for specific hardware, even more so as it is only available
with a proprietary driver stack, is not maintainable in the long run.
Most developers working on Weston either just cannot, or cannot bother
to test things also on the RPi. Breakage creeps in without anyone
noticing. If someone actually notices it, fixing it will require a very
specific environment to be able to test. Also the quality of the
proprietary implementation fluctuated. There are reports that RPi
firmware updates randomly broke Weston, and that nowadays it is very
hard to find a RPi firmware version that you could expect to work with
Weston if Weston itself was not broken. We are not even sure what is
broken nowadays.
This removal does not leave Raspberry Pi users cold (for long), though.
There is serious work going on in implementing a FOSS driver stack for
Raspberry Pi, including modern kernel DRM drivers and Mesa drivers. It
might not be fully there yet, but the plan is to be able to use the
standard DRM-backend of Weston on the RPis. See:
http://dri.freedesktop.org/wiki/VC4/
The rpi-backend had its moments. Now, it needs to go. Good riddance!
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Establishes a single variable for defining the libwayland version
requirements, where we have versioned checks. Enforces the same version
dependency between libwayland-client and libwayland-server. Developers
typically only test the greater version of the two, so if they're
different it masks cases that don't get tested adequately. So this sets
wayland-client's required version to 1.10, same as for the server.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Quentin Glidic <sardemff7+git@sardemff7.net>
FreeRDP 2.0 is about to be released, this allows to compile against this version.
The detection is adjusted to prefer FreeRDP 2 against version 1.x.
Signed-off-by: David Fort <contact@hardening-consulting.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
AC_SEARCH_LIBS is the recommended macro for these checks, unfortunately,
we use AC_CHECK_LIB instead, and even AC_CHECK_FUNC, when only one
AC_SEARCH_LIBS would be enough.
This wrapper macro is used much like PKG_CHECK_MODULES, as it defines
(and AC_SUBST) the PREFIX_LIBS variable itself.
It also avoids adding unnecessary stuff to LIBS.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
zuctest is another clock_gettime() user that fails to link against librt when
necessary.
Instead of adding another -lrt LDADD entry i've opted for the saner way and
converted the check to a configure test that will set CLOCK_GETTIME_LIBS
appropiately and replaced all instances of -lrt with it.
Built-tested against old and new glibc.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Systemd provides a feature of socket-based activation, details in [1]
This commit adds an implementation to check if sockets were provided by
systemd and adds this as an additional socket to wayland display.
before adding sockets are checked for the correctness:
only AF_UNIX of type SOCK_STREAM are accepted
This is usefull for early rendering use-cases where weston and
early-rendering-application can be started parallel.
[1] https://www.freedesktop.org/software/systemd/man/systemd.socket.html
Signed-off-by: Eugen Friedrich <efriedrich@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It doesn’t make sense to fail the entire build when jpeglib isn’t
present, so this commit makes it optional just like libwebp in the
previous one, disabled with --without-jpeg and forced with --with-jpeg.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Remove the unstable presentation_timing.xml file, and use
presentation-time.xml from wayland-protocols instead to generate all the
Presentation extension bindings.
The following renames are done according to the XML changes:
- generated header includes
- enum constants and macros prefixed with WP_
- interface symbol names prefixed with wp_
- protocol API calls prefixed with wp_
Clients use wp_presentation_interface.name rather than hardcoding the
global interface name: presentation-shm, weston-info, presentation-test.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
[Pekka: updated wayland-protocols dependency to 1.2]
The current way was enabling WebP support whenever libwebp was found,
giving no way to the user to disable it if they had the library
installed but didn’t want to link against it. This adds a
--without-webp configure option to never link against it, and a
--with-webp one to fail the build if it isn’t found, the default being
to use it if it is present.
Additionally, we now tell the user when WebP support has been disabled
and they try to load a WebP file.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
systemd-login support requires dbus (see "dbus.h" header in
"launcher-logind.c") but the configure script was only
checking libsystemd-login availability to define the
HAVE_SYSTEMD_LOGIN macro, which results in undefined
symbols in launcher-unit.
Put the systemd-login checks after the dbus ones, and only
run the checks if it is present. Also mention dbus in the
error message if "--enable-systemd-login" was forced.
Signed-off-by: Manuel Bachmann <manuel.bachmann@iot.bzh>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
This client opens a V4L2 device, usually exposed as /dev/videoN, and
retrieves its frames as dmabuf for later import into the compositor.
It supports both single- and multi-planar devices, and any format
exposed by the V4L2 device the Wayland compositor accepts.
This client never changes the v4l2 settings, use `v4l2-ctl -c` if you
want to change those.
Signed-off-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Tested-by: Derek Foreman <derekf@osg.samsung.com>
Maniphest Tasks: T90
Differential Revision: https://phabricator.freedesktop.org/D339
This client was using an Intel-specific way to allocate a dmabuf, so it
makes sense to have that in its name.
Signed-off-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Differential Revision: https://phabricator.freedesktop.org/D342
The required version only corresponds to version of mesa implementation.
This mesa version requirement causes configure errors,
when weston is configured for a different egl implementation than mesa.
Because the version of the egl drivers are not alligned
to the mesa version.
Therefore, I deleted the version controlling for egl,
so that weston can be configured for a different egl implementation.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
