Wayland

• Cagebreak — Based on cage, inspired by ratpoison.

https://github.com/project-repo/cagebreak || cagebreak^AUR cagebreak-bin^AUR

• Cardboard — Scrolling compositor, inspired by PaperWM, based on wlroots.

https://gitlab.com/cardboardwm/cardboard || cardboard-git^AUR

• dwl — dwm-like Wayland compositor based on wlroots.

https://github.com/djpohly/dwl || dwl^AUR

• japokwm — Dynamic Wayland tiling compositor based around creating layouts, based on wlroots.

https://github.com/werererer/japokwm || japokwm-git^AUR

• river — Dynamic tiling Wayland compositor inspired by dwm and bspwm.

https://github.com/ifreund/river || river^AUR

• waymonad — Wayland compositor inspired by xmonad written in Haskell.

https://github.com/waymonad/waymonad || not packaged? search in AUR

• Enlightenment — See Enlightenment#Manually. More Info:

https://www.enlightenment.org/ || enlightenment

• Weston — reference implementation of a Wayland compositor.

https://gitlab.freedesktop.org/wayland/weston || weston

• Motorcar — Wayland compositor to explore 3D windowing using virtual reality.

https://github.com/evil0sheep/motorcar || not packaged? search in AUR

Some of the above may support display managers. Check to see how they are started.

The and packages have the Wayland backend enabled. GTK will default to the Wayland backend, but it is possible to override it to Xwayland by modifying an environment variable: .

To enable Wayland support in Qt 5 or 6, install the qt5-wayland or package, respectively.

To run a Qt application with the Wayland plugin , use or environment variable. To force the usage of X11 on a Wayland session, use . This might be necessary for some proprietary applications that do not use the system's implementation of Qt, such as .

allows Qt to use the xcb (X11) plugin instead if Wayland is not available.

On some compositors, for example sway, Qt applications running natively might have missing functionality. For example, KeepassXC will be unable to minimize to tray. This can be solved by installing qt5ct and setting before running the application.

The Clutter toolkit has a Wayland backend that allows it to run as a Wayland client. The backend is enabled in the package.

To run a Clutter application on Wayland, set CLUTTER_BACKEND=wayland.

To run a SDL2 application on Wayland, set .

To use GLFW with the Wayland backend, install the package (instead of ).

The package currently still does not work with a lot of GLEW-based applications, so the only option is to use with Xwayland. See .

EFL has complete Wayland support. To run a EFL application on Wayland, see Wayland project page.

Winit is a window handling library in Rust. It will default to the Wayland backend, but it is possible to override it to Xwayland by modifying an environment variable: WINIT_UNIX_BACKEND=x11.

To use -based applications natively under Wayland, the following flags need to be added to your application exec command line: . This can be done directly or through a config file, see below for more details.

You can configure these flags per application with command line arguments, or globally with a user config file. Unfortunately, flags from the config file currently take precedence over flags passed on the command line, so if you need need some applications to have different configs, you should choose per application flags instead of per user.

Add the flags (e.g. ) to your application exec command line. You can probably do this by modifying the .desktop file and adding the flags to the end of the line.

Create or edit the file ${XDG_CONFIG_HOME}/electron-flags.conf and add the flags (one option per line), e.g.:

Note that older versions of electron require their own file. For example, if you have the package installed, you may wish to do

$ ln -s ~/.config/electron-flags.conf ~/.config/electron16-flags.conf

from within your directory (or maintain a separate ${XDG_CONFIG_HOME}/electron16-flags.conf file if you want different electron versions to use different runtime options).

The open source implementation of the Java platform OpenJDK, does not yet have native support for Wayland. Until Wakefield, which is the project that aims to implement Wayland in OpenJDK, XWayland can be used.

Note that enabling DRM KMS is required. Also note additional information in the official documentation regarding your display manager (e.g. GDM).

If you use , execute the following to see which windows use Xwayland or native Wayland, surfaces, input events, clipboard contents, and more.

$ qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole

To determine whether an application is running via Xwayland, you can run . Move your mouse pointer over the window of an application. If the red mouse moves, the application is running via Xwayland.

Alternatively, you can use and see if the eyes are moving, when moving the mouse pointer over an application window.

Wayland's security model prevents programs other than the compositor from grabbing raw keyboard input. Some compositors support remapping keys (for example, mutter through ), but many do not. The programs , , and work around this by grabbing the keyboard before the compositor, and passing modified keyboard input through to it.

See Backlight#Color correction.

Gnome-shell users may experience display issues when they switch to Wayland from X. One of the root cause might be the CLUTTER_PAINT=disable-clipped-redraws:disable-culling set by yourself for Xorg-based gnome-shell. Just try to remove it from or other rc files to see if everything goes back to normal.

Make sure you have not set . Setting it globally will break Electron applications.

• (20200206) (used by sway) offers a VNC backend via since version 0.10. RDP backend has been removed .
• (20180401) mutter has now remote desktop enabled at compile time, see and for details.
• There was a merge of FreeRDP into Weston in 2013, enabled via a compile flag. The package has it enabled since version 6.0.0.
• (or ) is a transparent proxy for Wayland applications, with a wrapper command to run over SSH

In contrast to Xorg, Wayland does not allow exclusive input device grabbing, also known as active or explicit grab (e.g. keyboard, mouse), instead, it depends on the Wayland compositor to pass keyboard shortcuts and confine the pointer device to the application window.

This change in input grabbing breaks current applications' behavior, meaning:

• Hotkey combinations and modifiers will be caught by the compositor and will not be sent to remote desktop and virtual machine windows.
• The mouse pointer will not be restricted to the application's window which might cause a parallax effect where the location of the mouse pointer inside the window of the virtual machine or remote desktop is displaced from the host's mouse pointer.

Wayland solves this by adding protocol extensions for Wayland and XWayland. Support for these extensions is needed to be added to the Wayland compositors. In the case of native Wayland clients, the used widget toolkits (e.g GTK, Qt) needs to support these extensions or the applications themselves if no widget toolkit is being used. In the case of Xorg applications, no changes in the applications or widget toolkits are needed as the XWayland support is enough.

These extensions are already included in , and supported by .

The related extensions are:

• XWayland keyboard grabbing protocol
• Compositor shortcuts inhibit protocol
• Relative pointer protocol
• Pointer constraints protocol

Supporting Wayland compositors:

• Mutter, GNOME's compositor since release 3.28
• wlroots supports relative-pointer and pointer-constraints

Supporting widget toolkits:

• GTK since release 3.22.18.

See https://github.com/swaywm/sway/wiki/GTK-3-settings-on-Wayland.

Add __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json as environment variable before launching a Wayland compositor like sway.