ca52b31d3f
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>
164 lines
5.5 KiB
Plaintext
164 lines
5.5 KiB
Plaintext
Weston
|
|
======
|
|
|
|
Weston is the reference implementation of a Wayland compositor, and a
|
|
useful compositor in its own right. Weston has various backends that
|
|
lets it run on Linux kernel modesetting and evdev input as well as
|
|
under X11. Weston ships with a few example clients, from simple
|
|
clients that demonstrate certain aspects of the protocol to more
|
|
complete clients and a simplistic toolkit. There is also a quite
|
|
capable terminal emulator (weston-terminal) and an toy/example desktop
|
|
shell. Finally, weston also provides integration with the Xorg server
|
|
and can pull X clients into the Wayland desktop and act as a X window
|
|
manager.
|
|
|
|
Refer to http://wayland.freedesktop.org/building.html for building
|
|
weston and its dependencies.
|
|
|
|
The test suite can be invoked via `make check`; see
|
|
http://wayland.freedesktop.org/testing.html for additional details.
|
|
|
|
Developer documentation can be built via `make doc`. Output will be in
|
|
the build root under
|
|
|
|
docs/developer/html/index.html
|
|
docs/tools/html/index.html
|
|
|
|
|
|
|
|
Libweston
|
|
=========
|
|
|
|
Libweston is an effort to separate the re-usable parts of Weston into
|
|
a library. Libweston provides most of the boring and tedious bits of
|
|
correctly implementing core Wayland protocols and interfacing with
|
|
input and output systems, so that people who just want to write a new
|
|
"Wayland window manager" (WM) or a small desktop environment (DE) can
|
|
focus on the WM part.
|
|
|
|
Libweston was first introduced in Weston 1.9, and is expected to
|
|
continue evolving through many Weston releases before it achieves a
|
|
stable API and feature completeness.
|
|
|
|
|
|
API (in)stability and parallel installability
|
|
---------------------------------------------
|
|
|
|
As libweston's API surface is huge, it is impossible to get it right
|
|
in one go. Therefore developers reserve the right to break the API
|
|
between every 1.x.0 Weston release (minor version bumps), just like
|
|
Weston's plugin API does. For git snapshots of the master branch, the
|
|
API can break any time without warning or version bump.
|
|
|
|
Libweston API or ABI will not be broken between Weston's stable
|
|
releases 1.x.0 and 1.x.y, where y < 90.
|
|
|
|
To make things tolerable for libweston users despite ABI breakages,
|
|
libweston is designed to be perfectly parallel-installable. An
|
|
ABI-version is defined for libweston, and it is bumped for releases as
|
|
needed. Different ABI-versions of libweston can be installed in
|
|
parallel, so that external projects can easily depend on a particular
|
|
ABI-version, and they do not have to fight over which ABI-version is
|
|
installed in a user's system. This allows a user to install many
|
|
different compositors each requiring a different libweston ABI-version
|
|
without tricks or conflicts.
|
|
|
|
Note, that versions of Weston itself will not be parallel-installable,
|
|
only libweston is.
|
|
|
|
For more information about parallel installability, see
|
|
http://ometer.com/parallel.html
|
|
|
|
|
|
Libweston design goals
|
|
----------------------
|
|
|
|
The high-level goal of libweston is that what used to be shell plugins
|
|
will be main executables. Instead of launching 'weston' with various
|
|
arguments to choose the shell, one would be launching
|
|
'weston-desktop', 'weston-ivi', 'orbital', etc. The main executable
|
|
(the hosting program) links to libweston for a fundamental compositor
|
|
implementation. Libweston is also intended for use by other projects
|
|
who want to create new "Wayland WMs".
|
|
|
|
The libweston API/ABI will be separating the shell logic and main
|
|
program from the rest of the "Weston compositor" (libweston
|
|
internals).
|
|
|
|
Details:
|
|
|
|
- All configuration and user interfaces will be outside of libweston.
|
|
This includes command line parsing, configuration files, and runtime
|
|
(graphical) UI.
|
|
|
|
- The hosting program (main executable) will be in full control of all
|
|
libweston options. Libweston should not have user settable options
|
|
that would work behind the hosting program's back, except perhaps
|
|
debugging features and such.
|
|
|
|
- Signal handling will be outside of libweston.
|
|
|
|
- Child process execution and management will be outside of libweston.
|
|
|
|
- The different backends (drm, fbdev, x11, etc) will be an internal
|
|
detail of libweston. Libweston will not support third party
|
|
backends. However, hosting programs need to handle
|
|
backend-specific configuration due to differences in behaviour and
|
|
available features.
|
|
|
|
- Renderers will be libweston internal details too, though again the
|
|
hosting program may affect the choice of renderer if the backend
|
|
allows, and maybe set renderer-specific options.
|
|
|
|
- plugin design ???
|
|
|
|
- xwayland ???
|
|
|
|
There are still many more details to be decided.
|
|
|
|
|
|
For packagers
|
|
-------------
|
|
|
|
Always build Weston with --with-cairo=image.
|
|
|
|
The Weston project is (will be) intended to be split into several
|
|
binary packages, each with its own dependencies. The maximal split
|
|
would be roughly like this:
|
|
|
|
- libweston (minimal dependencies):
|
|
+ headless backend
|
|
+ wayland backend
|
|
|
|
- gl-renderer (depends on GL libs etc.)
|
|
|
|
- drm-backend (depends on libdrm, libgbm, libudev, libinput, ...)
|
|
|
|
- x11-backend (depends of X11/xcb libs)
|
|
|
|
- xwayland (depends on X11/xcb libs)
|
|
|
|
- fbdev-backend (depends on libudev...)
|
|
|
|
- rdp-backend (depends on freerdp)
|
|
+ screen-share
|
|
|
|
- weston (the executable, not parallel-installable):
|
|
+ desktop shell
|
|
+ ivi-shell
|
|
+ fullscreen shell
|
|
+ weston-info, weston-terminal, etc. we install by default
|
|
|
|
- weston demos (not parallel-installable)
|
|
+ weston-simple-* programs
|
|
+ possibly all the programs we build but do not install by
|
|
default
|
|
|
|
- and possibly more...
|
|
|
|
Everything should be parallel-installable across libweston
|
|
ABI-versions, except those explicitly mentioned.
|
|
|
|
Weston's build may not sanely allow this yet, but this is the
|
|
intention.
|