Please comment below to contribute. Thanks!
| X11 concept | Wayland concept | Notes |
|---|---|---|
| "Window" | "Top-level Shell Surface" | An entire window, including window decorations |
| X11 (the specfication) | Wayland (the protocols) | Neither X11 nor Wayland are binaries that can be installed |
| Xorg, one universally shared default implementation | Multiple competing Wayland compositors | Unfortunately there is no universally used single Wayland compositor; apparently every desktop environment does its own, and as a result what works in one may not work in another |
export DISPLAY=... |
export WAYLAND_DISPLAY=... |
How to know which WAYLAND_DISPLAY one needs to export? The sockets (and their names) should be located in /run/user/*. If WAYLAND_SOCKET is detected, the client will prefer to use the socket provided using that environment variable. |
| X server | Wayland compositor | Unfortunately Wayland has no clear separation between the display server and the window manager |
| Window manager | Wayland compositor | Unfortunately Wayland has no clear separation between the display server and the window manager |
| Window ID | zwlr_foreign_toplevel_handle_v1, xdg_toplevel |
A zwlr_foreign_toplevel_handle_v1 is a window from a non-Wayland application, a xdg_toplevel is a window from a Wayland application |
./some-window-manager --replace |
??? | In a running session, replace the currently running window manager (compositor) with another one (e.g., for testing) |
/var/log/xorg.log |
??? Apparently you need to manually invoke your Wayland compositor of choice something like this: /usr/bin/yourwaylandcompositor >/tmp/yourwaylandcompositor.log 2>&1 |
The further splintering of the desktop by Wayland no longer providing elementary things like logging in a universally accepted way for everyone makes suporting it harder than before |
| Inter-Client Communication Conventions Manual (ICCCM) | wlr-foreign-toplevel-management-unstable-v1 (but it may not be supported everywhere, so no real solution) |
|
| Atoms (arbitrary properties) | Wayland doesn't have the concept of atoms | No smooth migration path (idea: put key-value pairs into title or app-id which are officially sanctioned properties) |
xprop |
No smooth migration path, since Wayland doesn't have the concept of atoms (arbitrary properties) | https://git.sr.ht/~leon_plickat/lswt can at least show the identifier, title and app-id (the only officially sanctioned properties?) of each window. But it works only if the compositor implements wlr_foreign_toplevel_management_unstable_v1, so one can be confident that it is broken somewhere |
| Root window | ? | The root window in X11 is what renders the desktop (e.g., wallpaper and the icons on the desktop). It needs to stay behind all other windows all the time. |
https://doc.qt.io/qt-5/qtwaylandcompositor-examples.html has example Wayland compositors written in Qt. Unfortunately they don't seem to be intended for productive use on the desktop, and are not based on wlroots (hence lacking functionality that wlroots-based Wayland compositors may have).
QWindow Compositor is a desktop-style Wayland compositor example that demonstrates the power of the Qt Wayland Compositor C++ APIs. However, it is lacking server side window decorations (like window title bars).
Running the following on Raspberry Pi OS in a default (Wayland) session results in the QWindow Compositor to run as a nested window on the desktop.
cd ~
git clone https://github.com/qt/qtwayland/
cd qtwayland
git checkout 5.15
cd ..
mkdir -p qwindow-compositor
cd qwindow-compositor
qmake ~/qtwayland/examples/wayland/qwindow-compositor/qwindow-compositor.pro
./qwindow-compositor &
export QT_WAYLAND_SHELL_INTEGRATION=wl-shell
export WAYLAND_DISPLAY=wayland-0 # How to know the value?
featherpad --platform wayland
If you get Failed to create wl_display then the compositor is not running or $WAYLAND_DISPLAY is wrong.
Server Side Decoration Compositor is a desktop-style Wayland compositor example implementing server-side window decorations. However, it is lacking minimize/maximize buttons.
sudo apt install qml-module-qtwayland-compositor
mkdir -p ~/server-side-decoration
cd ~/server-side-decoration
qmake ~/qtwayland/examples/wayland/server-side-decoration/server-side-decoration.pro
make -j4
./server-side-decoration &
export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
export WAYLAND_DISPLAY=wayland-0 # How to know the value?
featherpad --platform wayland
https://github.com/winft/como/tree/master/examples/minico
Doesn't even compile on Raspberry Pi OS (Debian stable) because it requires Qt and other components in versions newer than what is shipping. I don't have time for software that doesn't even compile without having the latest bleeding edge versions of everything. Software should not require anything at build time that is newer than what comes with Debian stable.
- How could one change Raspberry Pi OS to use such a compositor instead of the default one for the desktop session?
- How can one build a Qt based Wayland compositor that renders server side decorations using Qt Widgets rather than Qml?
- How woud one do drop shadows, round corners, fading, etc.?
- How can one bring in wlroots so that the Qt based compositor automatically supports everything that wlroots supports?
- Is there a full-fledged Qt based Wayland compositor suitable for the desktop but not as heavyweight in dependencies as KWin?
- https://github.com/ec1oud/grefsen - Desktop environment built on Qt and Wayland
- https://github.com/dcfranca/greenisland - The API extends QtCompositor with additional features needed by any real world Wayland compositor. Green Island offers multiple screen support and it also implements specific protocols such as xdg-shell, gtk-shell and those for Plasma 5. Also include a screencaster protocol and command line application, plus a minimal Wayland compositor written with QML. Unmaintained since 2015?
the sockets (and their names) should be located in /run/user/*