diff options
| author | Pekka Paalanen <pekka.paalanen@collabora.com> | 2022-03-15 11:17:56 +0200 |
|---|---|---|
| committer | Pekka Paalanen <pekka.paalanen@collabora.com> | 2022-03-15 11:32:46 +0200 |
| commit | b3ba1becba806a3557b8acbf8c42f1782cffdea2 (patch) | |
| tree | 74478a32cd403c49ec9d2a6562bf3584a2d8f0f8 /doc | |
| parent | 18df9108ea2ed6fa1ac82ce1d146dedfa9652d88 (diff) | |
| download | weston-b3ba1becba806a3557b8acbf8c42f1782cffdea2.tar.gz | |
libweston: remove fbdev backend
Fbdev backend was deprecated in the Weston 10.0.0 release with
6338dbd5816689b2f08f48b359a972e16ff038d8. 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>
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/sphinx/toc/running-weston.rst | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/doc/sphinx/toc/running-weston.rst b/doc/sphinx/toc/running-weston.rst index 15babf9d..39e95f1b 100644 --- a/doc/sphinx/toc/running-weston.rst +++ b/doc/sphinx/toc/running-weston.rst @@ -6,7 +6,7 @@ underlying environment where it runs on. Ultimately, the back-end is responsible for handling the input and generate an output. Weston, as a libweston user, can be run on different back-ends, including nested, by using the wayland backend, but also on X11 or on a stand-alone back-end like -DRM/KMS and now deprecated fbdev. +DRM/KMS. In most cases, people should allow Weston to choose the backend automatically as it will produce the best results. That happens for instance when running @@ -28,7 +28,6 @@ Available back-ends: * **x11** -- run as a x11 application, nested in a X11 display server instance * **rdp** -- run as an RDP server without local input or output * **headless** -- run without input or output, useful for test suite -* **fbdev** -- run stand-alone on fbdev/evdev (deprecated) The job of gathering all the surfaces (windows) being displayed on an output and stitching them together is performed by a *renderer*. By doing so, it is |