Wayland
________________________________________________________________________________
Wayland [0] is a display protocol that aims to be a simpler and modern
replacement for the X Window System. [1] The Wayland protocol follows a
client–server model in which clients are the graphical applications requesting
the display of pixel buffers on the screen, and the server (compositor) is the
service provider controlling the display of these buffers. [2]
Unlike Xorg, which is at the center of the universe (and everyone must talk to),
Wayland puts the Linux kernel and its components (DRI, DRM, etc) in the middle.
This effectively leaves the Wayland compositor off in the corner as its little
more than a special application. [3]
Wayland has been in development since September of 2008 [4] and is usable today
for a large number of use-cases. Some hardware configurations (namely NVIDIA
GPUs) [5] [6] and a number of features are not currently supported by
compositors.
Caveats
________________________________________________________________________________
While the Wayland protocol is more or less done, the growing list of compositors
are in differing stages of completeness. Xorg is still in wide use and a lot of
software still requires it.
The major downside to Wayland (compositors) is the reduction in choice. While
the Wayland protocol does not define what a compositor shall depend on, they
typically lock the user into udev, libinput and systemd/logind.
The lack of standardized, desktop-oriented protocols has created a situation
where software may only work in some compositors and not others. This should
improve over time as more protocols become standardized.
- Limited hardware and driver support. [5] [6] [7] [8]
- Non-standard and compositor specific software. [10] [11] [12]
- No Wayland support in SDL 1 (must use XWayland). [13]
- Starting compositors without logind requires SUID permissions. [14]
- Locked into using udev. [15]
Benefits
________________________________________________________________________________
Wayland has a large number of benefits and improvements over Xorg. The above
caveats do not apply to everyone (or every system). Those unaffected or willing
to live with the caveats will have no problem swapping over.
- Less moving parts [13], although some software still heavily relies on the
Xorg libraries (Mesa [16], Firefox [17], etc).
- No screen tearing by design [18].
- Hardware accelerated video playback in Firefox [19] and Webkit2GTK [20]
Prerequisites
________________________________________________________________________________
Though KISS does not support Wayland officially there is no problem in making it
capable through personal or 3rd party repositories. The official
repositories satisfy all dependencies. After "wayland" and "wayland-protocols"
are installed, some package adjustments are required to make them to known
citizens of your system.
NOTE: From this point it is expected that "wayland" and "wayland-protocols" are
installed and you have forked the required packages with modified
configure flags at the beginning of KISS_PATH. [21] Managing repositories
* Packages which need to be forked [23]:
firefox --enable-default-toolkit=cairo-gtk3-wayland
gtk+3 --enable-wayland-backend
mesa -Dplatforms=x11,drm,wayland
* Packages which pick up Wayland automatically at compile time [23]:
[needs expansion and verification]
cairo
intel-vaapi-driver
libva
mpv
pango
sdl2
webkit2gtk
Install Wayland on top Xorg KISS
________________________________________________________________________________
Mesa must be rebuilt first, followed by the aforementioned packages [22] in
a dependency given ascending order.
NOTE: kiss-revdepends is the tool you need.
mesa, cairo, pango, gtk+3, firefox/webkit2gtk
qt5-wayland
mpv
libva, intel-vaapi-driver
sdl2
$ kiss b mesa && kiss i mesa && kiss b pango && kiss i pango ...
Install Wayland on top base KISS
________________________________________________________________________________
Starting off a fresh base installation there is no manual intervention needed as
everything _should_ be autoconfigured.
[needs reproduction]
Post installation
________________________________________________________________________________
* In environments without systemd/elogind/consolekit the XDG_RUNTIME_DIR
variable must be set manually. [23] Export this in your shellrc.
+------------------------------------------------------------------------------+
| .ashrc, .bashrc, .zshrc, etc |
+------------------------------------------------------------------------------+
| |
| export XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR:-/tmp/$(id -u)-runtime-dir} |
| |
| [ -d "$XDG_RUNTIME_DIR" ] || { |
| mkdir -p "$XDG_RUNTIME_DIR" |
| chmod 0700 "$XDG_RUNTIME_DIR" |
| } |
| |
+------------------------------------------------------------------------------+
* Install a Compositor of your choosing.
References
________________________________________________________________________________
[0] https://wayland.freedesktop.org/
[1] https://wayland.freedesktop.org/faq.html#heading_toc_j_4
[2] https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)
[3] https://lwn.net/Articles/413335/
[4] https://cgit.freedesktop.org/wayland/wayland/commit/?id=97f1ebe8d5c2e166fabf757182c289fed266a45a
[5] https://github.com/swaywm/sway/issues/490
[6] https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
[7] $/swaywm/sway/wiki#nvidia-users
[8] https://wayland.freedesktop.org/building.html (Hardware / Drivers)
[10] $/Alexays/Waybar
[11] $/any1/wayvnc
[12] $/fzwoch/obs-gnome-screencast
[13] https://hansdegoede.livejournal.com/22212.html
[14] $/swaywm/sway/wiki/Running-Sway-without-systemd
[15] $/swaywm/wlroots#building #udev
[16] $/kiss-community/repo/blob/master/extra/mesa/depends
[17] $/kiss-community/repo-bin/blob/main/bin/firefox/depends
[18] https://people.freedesktop.org/~daniels/lca2013-wayland-x11.pdf
[19] https://bugzilla.mozilla.org/show_bug.cgi?id=1610199
[20] (webkit2gtk VAAPI source needed)
[21] #/kiss/managing-repositories
[22] https://wiki.gentoo.org/wiki/Sway#Other