Go to file
Arnaud Vrac 238d5274a2 fullscreen-shell: do not crash when presenting a null surface
The protocol allows presenting a null surface, in this case we would crash. This
can be reproduced with weston-fullscreen and pressing 'o'.

Signed-off-by: Arnaud Vrac <avrac@freebox.fr>
2024-02-21 18:14:18 +02:00
.gitlab-ci gitlab-ci: build and install LittleCMS version 2.16 2024-02-14 12:13:04 -03:00
clients clients/simple-damage: fix exiting message 2024-02-20 10:04:57 +00:00
data build: Switch join_paths(foo, bar) to foo / bar 2023-06-22 14:31:57 +01:00
desktop-shell Fix segfault when using fullscreen when just hotplugging the display 2024-02-21 17:22:31 +08:00
doc launcher: Remove launcher-logind 2023-09-29 09:55:32 -05:00
frontend compositor/main: warn pipewire-output and remote-output 2024-02-21 09:49:23 +00:00
fullscreen-shell fullscreen-shell: do not crash when presenting a null surface 2024-02-21 18:14:18 +02:00
include color: add support to the color-management protocol 2024-02-14 11:15:35 -03:00
ivi-shell ivi-shell: clear seat focus if necessary when a surface is destroyed 2023-12-18 21:39:24 +00:00
kiosk-shell Rename compositor/ to frontend/ 2023-12-18 15:34:26 +00:00
libweston backend-drm: Cleanup output's disable head list when destroying it 2024-02-21 11:14:23 +00:00
man man: Document the new 'command input' feature 2024-01-26 09:32:46 +00:00
pam libweston: Add user authentication support via PAM 2022-11-23 16:58:48 +01:00
pipewire backend-drm,pipewire,remoting: do not set monitor serial to "unknown" 2023-09-15 06:56:59 +00:00
protocol protocol: add color-management-v2.xml 2024-02-13 14:15:31 -03:00
remoting backend-drm,pipewire,remoting: do not set monitor serial to "unknown" 2023-09-15 06:56:59 +00:00
shared color: add support to the color-management protocol 2024-02-14 11:15:35 -03:00
subprojects neatvnc.wrap: Update to neatvnc 0.7.0 2023-10-10 10:33:51 +00:00
tests tests: add tests for the color management protocol implementation 2024-02-14 12:13:04 -03:00
tools libweston,tools: Include libgen.h for basename signature 2023-12-18 21:13:52 +00:00
wcap build: simplify include_directories 2019-10-04 17:14:22 +03:00
xwayland libweston/desktop: Update my Copyright 2024-02-11 19:07:39 +01:00
.editorconfig Fix .editorconfig: use tabs for Meson files 2019-02-18 11:21:07 +01:00
.gitignore gitignore: Ignore the build/ directory. 2021-07-06 18:46:09 +00:00
.gitlab-ci.yml gitlab-ci: build and install LittleCMS version 2.16 2024-02-14 12:13:04 -03:00
.mailmap Add a .mailmap file 2023-03-25 11:18:10 -05:00
CONTRIBUTING.md CONTRIBUTING.md: Fix link for patchwork 2023-04-20 09:46:51 +03:00
COPYING COPYING: Specify origin of the library 2015-06-15 13:04:19 -07:00
DCO-1.1.txt contributing: add copy of DCO 2019-07-16 11:43:57 +00:00
meson_options.txt libweston: Remove dbus helpers 2023-09-29 09:58:01 -05:00
meson.build color: always set HAVE_LCMS when LittleCMS dependency is found 2024-02-13 08:59:57 -03:00
notes.txt notes: fix a typo 2017-01-03 11:59:01 +00:00
README.md frontend: Use short-form names for shell argument 2023-01-10 10:53:02 +02:00
releasing.md releasing: use the Wayland release script 2022-11-10 11:22:54 +02:00
weston.ini.in frontend: Use short-form names for shell argument 2023-01-10 10:53:02 +02:00

Weston

screenshot of skeletal Weston desktop

Weston is a Wayland compositor designed for correctness, reliability, predictability, and performance.

Out of the box, Weston provides a very basic desktop, or a full-featured environment for non-desktop uses such as automotive, embedded, in-flight, industrial, kiosks, set-top boxes and TVs.

It also provides a library called libweston which allows users to build their own custom full-featured environments on top of Weston's core.

Building Weston

Weston is built using Meson. Weston often depends on the current release versions of Wayland and wayland-protocols.

If necessary, the latest Meson can be installed as a user with:

$ pip3 install --user meson

Weston's Meson build does not do autodetection and it defaults to all features enabled, which means you likely hit missing dependencies on the first try. If a dependency is avoidable through a build option, the error message should tell you what option can be used to avoid it. You may need to disable several features if you want to avoid certain dependencies.

$ git clone https://gitlab.freedesktop.org/wayland/weston.git
$ cd weston
$ meson build/ --prefix=...
$ ninja -C build/ install
$ cd ..

The meson command populates the build directory. This step can fail due to missing dependencies. Any build options you want can be added on that line, e.g. meson build/ --prefix=... -Ddemo-clients=false. All the build options can be found in the file meson_options.txt.

Once the build directory has been successfully populated, you can inspect the configuration with meson configure build/. If you need to change an option, you can do e.g. meson configure build/ -Ddemo-clients=false.

Every push to the Weston master repository and its forks is built using GitLab CI. Reading the configuration may provide a useful example of how to build and install Weston.

More detailed documentation on building Weston is available on the Wayland site. There are also more details on how to run and write tests.

For building the documentation see documentation.

Running Weston

Once Weston is installed, most users can simply run it by typing weston. This will launch Weston inside whatever environment you launch it from: when launched from a text console, it will take over that console. When launched from inside an existing Wayland or X11 session, it will start a 'nested' instance of Weston inside a window in that session.

By default, Weston will start with a skeletal desktop-like environment called desktop-shell. Other shells are available; for example, to load the kiosk shell designed for single-application environments, you can start with:

$ weston --shell=kiosk

Help is available by running weston --help, or man weston, which will list the available configuration options and display backends. It can also be configured through a file on disk; more information on this can be found through man weston.ini.

A small suite of example or demo clients are also provided: though they can be useful in themselves, their main purpose is to be an example or test case for others building compositors or clients.

Using libweston

libweston is designed to allow users to use Weston's core - its client support, backends and renderers - whilst implementing their own user interface, policy, configuration, and lifecycle. If you would like to implement your own window manager or desktop environment, we recommend building your project using the libweston API.

Building and installing Weston will also install libweston's shared library and development headers. libweston is both API-compatible and ABI-compatible within a single stable release. It is parallel-installable, so multiple stable releases can be installed and used side by side.

Documentation for libweston's API can be found within the source (see the documentation section), and also on Weston's online documentation for the current stable release.

Reporting issues and contributing

Weston's development is hosted on freedesktop.org GitLab. Please also see the contributing document, which details how to make code or non-technical contributions to Weston.

Weston and libweston are not suitable for severely memory-constrained environments where the compositor is expected to continue running even in the face of trivial memory allocations failing. If standard functions like malloc() fail for small allocations, you can expect libweston to abort. This is only likely to occur if you have disabled your OS's 'overcommit' functionality, and not in common cases.

Documentation

To read the Weston documentation online, head over to the Weston website.

For documenting weston we use sphinx together with breathe to process and augment code documentation from Doxygen. You should be able to install both sphinx and the breathe extension using pip3 command, or your package manager. Doxygen should be available using your distribution package manager.

Once those are set up, run meson with -Ddoc=true option in order to enable building the documentation. Installation will place the documentation in the prefix's path under datadir (i.e., share/doc).

Adding and improving documentation

For re-generating the documentation a special docs target has been added. Although first time you build (and subsequently install) weston, you'll see the documentation being built, updates to the spinx documentation files or to the source files will only be updated when using docs target!

Example:

$ ninja install # generates and installs the documentation
# time passes, hack hack, add doc in sources or rST files
$ ninja install # not sufficient, docs will not be updated
$ ninja docs && ninja install # run 'docs' then install

Improving/adding documentation can be done by modifying rST files under doc/sphinx/ directory or by modifying the source code using doxygen directives.