Wayland est un protocole de serveur d’affichage. Il a pour objectif de devenir le successeur du système X Window. Vous pouvez trouver une comparaison entre Wayland et Xorg sur Wikipedia.
Les serveurs d’affichage utilisant le protocole Wayland sont appelés compositeurs car ils agissent également comme des gestionnaires de fenêtres de composition. Vous trouverez ci-dessous une liste de compositeurs Wayland.
Pour une compatibilité ascendante afin d’exécuter de manière transparente les applications X11 héritées, XWayland peut être utilisé, ce qui fournit un serveur X dans Wayland.
Requirements
La plupart des compositeurs Wayland ne fonctionnent que sur des systèmes utilisant le réglage du mode Kernel. Wayland en lui-même ne fournit pas d’environnement graphique ; pour cela, vous avez également besoin d’un compositeur (voir la section suivante), ou d’un environnement de bureau qui inclut un compositeur (par exemple GNOME ou KDE).
Pour que le pilote GPU et le compositeur Wayland soient compatibles, ils doivent supporter la même API de tampon. Il existe deux API principales : GBM et EGLStreams.
| API tampon | Support du pilote GPU | Support du compositeur Wayland |
|---|---|---|
| GBM | Tout sauf NVIDIA | Tout |
| EGLStreams | NVIDIA | GNOME, KDE, Weston (avec un patch tiers) |
Compositeurs
Voir Window manager#Types pour la différence entre Tiling et Stacking.
Tiling
- Cagebreak – Basé sur cage, inspiré par ratpoison.
https://github.com/project-repo/cagebreak || cagebreakAUR cagebreak-binAUR
- Cardboard – Compositeur défilant, inspiré par PaperWM, basé sur wlroots.
https://gitlab.com/cardboardwm/cardboard || non empaqueté ? chercher dans AUR
- dwl – Compositeur Wayland de type dwm basé sur wlroots.
https://github.com/djpohly/dwl || dwlAUR
- japokwm – Compositeur dynamique de tuilage Wayland basé autour de la création de layouts, basé sur wlroots.
https://github.com/werererer/japokwm || non packagé ? chercher dans AUR
- river – Compositeur dynamique de tuilage Wayland inspiré par dwm et bspwm.
https://github.com/ifreund/river || river-gitAUR
- Sway – Compositeur Wayland compatible i3 basé sur wlroots.
https://github.com/swaywm/sway || sway
- Velox – Gestionnaire de fenêtres simple basé sur swc, inspiré par dwm et xmonad.
https://github.com/michaelforney/velox || veloxAUR
- waymonad – Compositeur Wayland inspiré par xmonad écrit en Haskell.
https://github.com/waymonad/waymonad || pas empaqueté ? chercher dans AUR
Stacking
- Enlightenment – Voir Enlightenment#Manually. Plus d’infos :
https://www.enlightenment.org/ || enlightenment
- Greenfield – Fonctionne dans un navigateur web et peut afficher des applications distantes.
https://greenfield.app/ || non packagé ? rechercher dans AUR
- Grefsen – Compositeur Qt/Wayland fournissant un environnement de bureau minimal.
https://github.com/ec1oud/grefsen || non packagé ? rechercher dans AUR
- hikari – compositeur basé sur wlroots inspiré de cwm qui est activement développé sur FreeBSD mais supporte aussi Linux.
https://hikari.acmelabs.space/ || hikariAUR
- KDE KWin – Voir KDE#Starting Plasma.
https://userbase.kde.org/KWin || kwin
- Liri Shell – Partie de Liri, construit en utilisant QtQuick et QtCompositor comme compositeur pour Wayland.
https://github.com/lirios/shell || liri-shell-gitAUR
- labwc – Compositeur basé sur wlroots inspiré par Openbox.
https://github.com/johanmalm/labwc || labwc-gitAUR
- Mutter – Voir GNOME#Starting.
https://gitlab.gnome.org/GNOME/mutter || mutter
- wayfire – compositeur 3D inspiré de Compiz et basé sur wlroots.
https://wayfire.org/ || wayfireAUR
- Weston – implémentation de référence d’un compositeur Wayland.
https://gitlab.freedesktop.org/wayland/weston || weston
- wio – compositeur basé sur wlroots qui vise à reproduire l’apparence du bureau Rio de Plan 9.
https://wio-project.org/ || non packagé ? chercher dans AUR
Autres
- Cage – Affiche une seule application en plein écran comme un kiosque.
https://www.hjdskes.nl/projects/cage/ || cage
- Maze Compositor – Rend les fenêtres dans un labyrinthe 3D en utilisant Qt.
https://github.com/imbavirus/mazecompositor || non packagé ? chercher dans AUR
- Motorcar – Compositeur Wayland pour explorer le fenêtrage 3D en utilisant la réalité virtuelle.
https://github.com/evil0sheep/motorcar || non packagé ? chercher dans AUR
Certains des éléments ci-dessus peuvent supporter les gestionnaires d’affichage. Vérifiez /usr/share/wayland-sessions/compositor.desktop pour voir comment ils sont lancés.
Gestionnaires d’affichage
Les gestionnaires d’affichage listés ci-dessous prennent en charge le lancement des compositeurs Wayland. La colonne « Type » indique si le gestionnaire d’affichage prend en charge son propre fonctionnement sur Wayland ou non.
| Nom | Type | Description |
|---|---|---|
| GDM | Fonctionne sur Wayland | Gestionnaire d’affichage GNOME. |
| greetd | Démon de connexion | Démon de connexion minimal et flexible. |
| LightDM | Exécution sur X11 | Gestionnaire d’affichage multi-bureau. |
| Ly | Exécution en console | Gestionnaire d’affichageTUI écrit en C |
| SDDM | Exécution sur X11 | Gestionnaire d’affichage basé sur QML. |
| tbsm | Exécution en console | Lanceur de session CLI simple écrit en bash pur. |
Bibliothèques d’interface utilisateur
Voir détails sur le site officiel.
GTK
Les paquets gtk3 et gtk4 ont le backend Wayland activé. GTK utilisera par défaut le backend Wayland, mais il est possible de le remplacer par Xwayland en modifiant une variable d’environnement : GDK_BACKEND=x11.
Qt
Pour activer le support Wayland dans Qt 5 ou 6, installez respectivement le paquet qt5-wayland ou qt6-wayland.
Pour exécuter une application Qt avec le plugin Wayland , utilisez la variable d’environnement -platform wayland ou QT_QPA_PLATFORM=wayland. Pour forcer l’utilisation de X11 sur une session Wayland, utilisez QT_QPA_PLATFORM=xcb. Cela pourrait être nécessaire pour certaines applications propriétaires qui n’utilisent pas l’implémentation de Qt du système, comme zoomAUR.
Sur certains compositeurs, par exemple sway, les applications Qt s’exécutant nativement pourraient avoir des fonctionnalités manquantes. Par exemple, KeepassXC sera incapable de minimiser à la barre des tâches. Cela peut être résolu en installant qt5ct et en définissant QT_QPA_PLATFORMTHEME=qt5ct avant d’exécuter l’application.
Clutter
La boîte à outils Clutter possède un backend Wayland qui lui permet de s’exécuter comme un client Wayland. Le backend est activé dans le paquet clutter.
Pour exécuter une application Clutter sur Wayland, définissez CLUTTER_BACKEND=wayland.
SDL2
Pour exécuter une application SDL2 sur Wayland, définissez SDL_VIDEODRIVER=wayland.
SDL_VIDEODRIVER=wayland. Pour forcer l’application à s’exécuter avec XWayland, définissez SDL_VIDEODRIVER=x11.GLFW
Pour utiliser GLFW avec le backend Wayland, installez le paquet glfw-wayland (au lieu de glfw-x11).
GLEW
Le paquet glew-waylandAUR ne fonctionne actuellement toujours pas avec beaucoup d’applications basées sur GLEW, donc la seule option est d’utiliser glew avec Xwayland. Voir FS#62713.
EFL
EFL a un support complet de Wayland. Pour exécuter une application EFL sur Wayland, voir la page du projet Wayland.
winit
Winit est une bibliothèque de gestion des fenêtres en Rust. Elle utilisera par défaut le backend Wayland, mais il est possible de la remplacer par Xwayland en modifiant une variable d’environnement : WINIT_UNIX_BACKEND=x11.
XWayland
XWayland est un serveur X qui fonctionne sous Wayland. Il fournit une compatibilité ascendante pour les applications X11 héritées.
Pour l’utiliser, installez le paquet xorg-xwayland.
XWayland est démarré via un compositeur, vous devez donc vérifier la compatibilité XWayland et les instructions sur la façon de démarrer XWayland, avec le compositeur de votre choix.
- En ce qui concerne la sécurité : XWayland est un serveur X, il ne dispose donc pas des fonctionnalités de sécurité de Wayland !
- Pour l’instant, le pilote propriétaire Nvidia ne prend pas en charge l’accélération GPU pour XWayland. Voir ceci ou cette pull request pour le statut du support de XWayland.
Dépannage
Correction des couleurs
Voir Rétroéclairage#Correction des couleurs.
Retards, accrocs graphiques et plantages
Les utilisateurs de gnome-shell peuvent rencontrer des problèmes d’affichage lorsqu’ils passent de X à Wayland. L’une des causes fondamentales pourrait être le CLUTTER_PAINT=disable-clipped-redraws:disable-cullingréglage par vous-même pour gnome-shell basé sur Xorg. Essayez simplement de le supprimer de /etc/environment ou d’autres fichiers rc pour voir si tout revient à la normale.
Canot open display : :0 with Electron-based applications
Vérifiez que vous n’avez pas défini GDK_BACKEND=wayland. Le définir globalement cassera les applications Electron.
Affichage à distance
- (20200206) wlroots (utilisé par sway) offre un backend VNC via wayvncAUR depuis la version 0.10. Le backend RDP a été supprimé. .
- (20180401) mutter a maintenant le bureau à distance activé au moment de la compilation, voir et gnome-remote-desktop pour les détails.
- Il y a eu une fusion de FreeRDP dans Weston en 2013, activé via un drapeau de compilation. Le paquet weston l’a activé depuis la version 6.0.0.
- waypipe-gitAUR est un proxy transparent pour les applications Wayland, avec une commande wrapper à exécuter sur SSH
Input grabbing dans les jeux, le bureau à distance et les fenêtres VM
Contrairement à Xorg, Wayland ne permet pas la saisie exclusive de périphériques d’entrée, également connue sous le nom de saisie active ou explicite (par ex.g. clavier, souris), au lieu de cela, il dépend du compositeur Wayland pour passer les raccourcis clavier et confiner le périphérique pointeur à la fenêtre de l’application.
Ce changement dans la saisie des entrées brise le comportement des applications actuelles, ce qui signifie :
- Les combinaisons et les modificateurs Hotkey seront capturés par le compositeur et ne seront pas envoyés aux fenêtres du bureau distant et de la machine virtuelle.
- Le pointeur de la souris ne sera pas limité à la fenêtre de l’application, ce qui pourrait provoquer un effet de parallaxe où l’emplacement du pointeur de la souris à l’intérieur de la fenêtre de la machine virtuelle ou du bureau distant est déplacé par rapport au pointeur de la souris de l’hôte.
Wayland résout ce problème en ajoutant des extensions de protocole pour Wayland et XWayland. Le support de ces extensions est nécessaire pour être ajouté aux compositeurs Wayland. Dans le cas des clients Wayland natifs, les boîtes à outils widgets utilisées (par exemple GTK, Qt) doivent supporter ces extensions ou les applications elles-mêmes si aucune boîte à outils widgets n’est utilisée. Dans le cas des applications Xorg, aucun changement dans les applications ou les boîtes à outils widgets n’est nécessaire car le support XWayland est suffisant.
Ces extensions sont déjà incluses dans wayland-protocols, et supportées par xorg-xwayland.
Les extensions connexes sont:
- Protocole de saisie du clavier de XWayland
- Protocole d’inhibition des raccourcis du compositeur
- Protocole de pointeur relatif
- Protocole de contraintes de pointeur
Support des compositeurs Wayland:
- Mutter, le compositeur de GNOME depuis la version 3.28
- wlroots supporte les contraintes de pointeur relatif et de pointeur
Support des boîtes à outils de widgets:
- GTK depuis la version 3.22.18.
Voir aussi
- Documentation Wayland en ligne
- Répo Git officiel Wayland
- Fedora :Comment déboguer les problèmes de Wayland
- Des projets Wayland géniaux
- Thèmes de curseurs
- Discussion sur le forum d’Arch Linux
- Guide de migration i3 – Applications X11 courantes utilisées sur i3 avec des alternatives Wayland
.