Fbdev backend was deprecated in the Weston 10.0.0 release with
6338dbd581. Before that, I suggested
already in 2019 to remove it, but it was too soon then. Now it seems the
final voices asking for fbdev to be kept have been satisfied, see the
linked issue.
Fbdev-backend uses a kernel graphics UAPI (fbdev) which is sub-par for a
Wayland compositor: you cannot do GPU accelerated graphics in any
reasonable way, no hotplug support, multi-output support is tedious, and
so on. Most importantly, Linux has deprecated fbdev a long time ago due
to the UAPI fitting modern systems and use cases very poorly, but cannot
get rid of it if any users remain. Let's do here what we can to reduce
fbdev usage.
I am doing color management related additions to libweston which require
adding checks to every backend. One backend less is less churn to write
and review.
Libweston major version has already been bumped to 11, so the next
release will be Weston 11, without fbdev. enum weston_compositor_backend
entries change their numerical values.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/581
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that launcher-direct and weston-launch are gone, libseat takes their
place.
Enable libseat support by default to give users a hint in case they miss
either of those.
People who used to get launcher-logind when libseat support was disabled
will now be using logind through libseat. This should not cause any
regressions, and if it does, we want to hear about them, because the
separate logind-launcher is also planned to be deprecated in the future.
Disabling logind-launcher by default is left for when it actually gets
deprecated.
In case someone does not have libseat available but do have logind
running, they can just disable libseat support.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Moving forward we're going to be supporting libseat and logind as our
only launchers. We're doing this to reduce our maintenance burden,
and security impact.
Libseat supports all our existing use cases, and seatd can replace
weston-launch so we no longer have to carry a setuid-root program.
This patch removes weston-launch, and launcher-direct, leaving only
libseat and logind.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This ensures that users that previously set the option explicitly will also have
a chance to notice the deprecation.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
While the option is still available, this brings more attention to the
upcoming deprecation of weston-launch.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Rename the build option to "deprecated-backend-fbdev" so that a
previously configured build dir doesn't retain the old setting.
This is consistent with the existing "deprecated-wl-shell" option.
Make the option default to "false".
Print a warning when fbdev is force-enabled.
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/wayland/weston/-/issues/581
Simple client to test the dma-buf feedback implementation. This does not
replace the need to implement a dma-buf feedback test that can be run in
the CI. But as we still don't know exactly how to do this, this client
can be helpful to run tests manually.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This is the first step towards removing wl_shell support.
Add an option so that users can toggle support for the deprecated
wl_shell protocol. This lets users test their clients to make sure
they work fine without wl_shell.
The option is set to false by default.
Signed-off-by: Simon Ser <contact@emersion.fr>
This creates the color-lcms plugin that in the future will be using
Little CMS as the color matching module, processing ICC profiles, and
producing HDR tone mappings.
Right now, this new plugin is functionally equivalent to the no-op color
manager, except it already links to lcms2 and checks that the renderer
supports color operations.
Color-lcms is a libweston plugin that is loaded with explicit
weston_compositor API. This does not currently allow loading alternative
color manager plugins. External color manager plugins might be
considered in the future when the libweston APIs around color management
stabilize.
This libweston plugin uses the same build option as the old cms-static
Weston plugins, as they both need lcms2. The minimum version for lcms2
was chosen by what Debian Buster provides today and for no other reason.
This plugin intends to support the Wayland CM&HDR protocol extension and
hence sets supports_client_protocol to true. This will expose the
protocol extension to clients when it gets implemented.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds support for libseat as a seat backend. libseat provides seatd,
(e)logind and direct seat backends as compile-time and runtime options.
The backend is currently disabled by default. It can be enabled through the
launcher-libseat option.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
This will be useful in CI, where we do not want to see any skips. If
something starts to skip, that's a mistake somewhere, and want to catch
it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
kiosk-shell is fullscreen shell for apps that use the xdg-shell
protocol. The goal is to make life easier for people shipping embedded
devices with simple fullscreen shell requirements, and reduce the
proliferation of desktop-shell hacks.
Top level surfaces are made fullscreen, whereas dialogs are placed on
top in the center of the output and retain their natural sizes. Dialogs
can be moved and (un)maximized, but resizing is currently not supported.
An app can be directed to a particular output by populating the
"app-ids" field with the app's XDG app id, in the relevant
"[output]" section in the weston config file.
Fixes: #277
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
This shall be used by CI due to https://gitlab.freedesktop.org/mesa/mesa/issues/2219
It defaults to true, meaning that people by default will be running the
GL-renderer tests. It works fine on hardware drivers, just not llvmpipe.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This client contains driver-specific code to allocate buffers. However clients
shouldn't contain driver-specific code and should rely on e.g. mesa to allocate
buffers via standard interfaces.
Additionally, because the build system always tries to enable all features, some
experimental drivers and drivers that aren't included in amd64 distribution
packages were required. Users would need to manually disable some drivers.
Releasers would need to install libdrm from source (because the release process
forbids adding custom build flags). Dropping simple-dmabuf-drm simplifies both
building and releasing.
The functionality previously tested via simple-dmabuf-drm can now be tested with
simple-dmabuf-egl.
Signed-off-by: Simon Ser <contact@emersion.fr>
It is quite similar to the remoting plugin. It just exports the frames via
pipewire instead of the builtin GStreamer pipeline.
It implements the same virtual output API. Virtual outputs can be created
by adding 'pipewire-output' sections to weston.ini.
The generated frames can be accessed with any pipewire client. e.g. with
GStreamer:
gst-launch-1.0 pipewiresrc ! video/x-raw,format=BGRx ! ...
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This is adds basic configuration files for doxygen and for breathe,
which is a doxygen-to-sphinx bridge that can document C symbols.
Breathe is configured with default project 'weston' and implicitly adds
:members: and :undoc-members: to breathe configuration options.
This allows a shorter way to call breathe directives without the need
specify the project and also to display implicitly all the members,
documented or not.
A 'docs' run_target to force the docs to be re-built has been added.
Initially (the first time the build system is ran) the documentation
will automatically be built, but later re-builds will require the use of
the 'docs' target. This avoid further delays in building weston but in
the same time allows the possiblity to update/improve the documentation
bits to those who want that.
Signed-off-by: Marius Vlad <marius.vlad@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