Wayland (Français)

Wayland est un nouveau protocole de fenêtrage pour Linux (très grossièrement, il regroupe système X et compositeur et se veut donc plus simple et efficace). Pour plus d'informations sur Wayland, consultez le site du projet.

Exigences

La grande majorité des compositeurs fonctionnent seulement sur les systèmes utilisant KMS.

Wayland ne fournit pas lui même d’environnement graphique, pour cela vous aurez besoin d'un compositeur ou d'un environnement graphique (comme GNOME (Français) ou KDE (Français)).

Pour qu'un driver de carte graphique fonctionne avec un compositeur donné, tous deux doivent prendre en charge une même API. Les deux principales API étant: GBM et EGLStreams.

Buffer APIprends en charge les pilotes de GPUprends en charge les compositeurs
GBMtous sauf NVIDIA (Français)tous
EGLStreamsNVIDIA (Français)GNOME (Français), KDE (Français), Weston (Français)

Installation

pacman -Syu wayland
Note: La version en cours de développement est disponible depuis AUR: wayland-gitAUR.

Gestionnaire de connexions

Les gestionnaires de connexions suivants sont tous capable de démarrer un compositeur Wayland. La colonne «type» indique si le gestionnaire de connexion, fonctionne lui-même sous Wayand.

Name Type Description
GDM (Français) Wayland GNOME (Français) display manager.
greetdAUR remplace login «login daemon» minimal et flexible
LightDM (Français) X11 prends en charge X11, Wayland, et Mir !
Console gestionnaire de connexions, en mode texte, écrit en C
SDDM (Français) X11 QML-based display manager.
Console «lanceur» de session écrit en bash.

Utilisation

Les applications graphiques font généralement usage de bibliothèques de ressources. Certaines dépendent directement de Xorg (Français), (notamment par l'intermédiaire de la bibliothèque ). D'autres prennent en charge nativement Wayland, et, d'autres enfin ont besoin d'ajustements pour utiliser Wayland.

Gtk

Les paquets , gtk4 utilisent par défaut l'infrastructure Wayland. Il est aussi possible de passer par Xwayland en exportant:

Qt

Pour activer la prise en charge de Wayland, sur Qt 5 et Qt 6 installez respectivement et qt6-wayland.

Pour utiliser une application Qt avec le plugin Wayland, utilisez ou la variable d'environnement . Pour forcer l'usage de Xorg lors d'une session Wayland, utilisez avant de démarrer cette application. Ce pourrait être utile avec certaines applications propriétaires telles .

Sur certains compositeurs, notamment sway, certaines fonctionnalités pourraient manquer à quelques applications. Par exemple, , ne peut être minimisé vers la barre des tâches. Ceci peut être résolu en installant , et en exportant la variable QT_QPA_PLATFORMTHEME=qt5ct avant de démarrer ladite application.

Clutter

Le toolkit clutter possède une infrastructure qui lui permet de fonctionner comme un client Wayland. Le paquet vient avec cette fonctionnalité. Il suffit d’exporter .

SDL2

Pour les applications SDL2 sur Wayland, utilisez SDL_VIDEODRIVER=wayland

GLFW

Pour les programmes écrits avec GLFW, installez simplement en remplacement du paquet .

GLEW

le paquet ne fonctionne mal pour de nombreuses applications basées sur GLEW. La meilleure option reste actuellement d'utiliser conjointement à Xwayland. ( cf. bug_FS#62713 )

XWayland

Pour pouvoir utiliser les applications qui ne prendraient en charge que le serveur X (xterm?) par dessus Wayland, vous pouvez installer .

XWayland fournie une compatibilité ascendante aux applications qui le nécessitent, cependant, il doit être démarré depuis un compositeur. Aussi, veillez à vérifier la compatibilité de ce dernier avec Xwayland, ainsi que les instructions spécifiques à sa mise en place, en fonction du compositeur.

Note:
  • Concernant la sécurité: XWayland est un serveur X , et ne présente pas les mêmes gages de sécurité que Wayland!
  • Pour l'instant le pilote propriétaire Nvidia ne prends pas en charge l’accélération matériel depuis XWayland. Voir cette pull request.

Autres bibliothèques

Les choses évoluent vites, voyez Wayland et pour plus d'infos.

Différences avec Xorg

X fonctionne sur le principe d'un serveur, c'est à dire, qu'il est supposé faire tout le boulot pour ses clients... Les clients de X, ce sont les programmes dotés d'interfaces graphiques. Les clients de X lui demandent d'afficher une image à cet endroit de l'écran, un texte ici, un carré bleu là bas.... X interprète le tout, dessine une image, et l'envoie là ou il doit (généralement c'est l'écran, mais X peut aussi fonctionner au travers d'un réseau). Le problème est qu'il est impossible lors de l'écriture d'un programme de savoir à l'avance dans quel état sera l'écran. Et deux programmes peuvent, par exemple, demander à afficher quelque chose au même endroit de l'écran!

Pour gérer genre de cas, il faut implémenter dans chacun de nos programmes une routine qui sache communiquer avec X pour lui dire quoi faire (déplacer la fenêtre, la passer en arrière-plan...). Cependant, les développeurs n'ont pas besoin d'écrire des programmes qui se préoccupent de ne pas se déranger les uns les autres, ou de réinventer la roue.

Un gestionnaire de fenêtres (qui n'est qu'un client X parmi d'autres) vient simplifier la donne en réclamant pour lui seul la totalité de l'écran. Dès lors quand un évènement se produit (que ce soit un clic, une pression du clavier, ou autre), cet évènement lui est transmis. En fonction de la position de la souris, de l'application en avant-plan, et des autres paramètres qui le concernent, le gestionnaire de fenêtre demande alors à X de retransmettre l’événement à l'application concernée. Celle-ci interprète l'évènement, et demande l'aide de X pour calculer sa nouvelle apparence. Sitôt fait, X prévient le gestionnaire de fenêtres qu'une application a changé d'apparence. Alors seulement le gestionnaire de fenêtres calcule la nouvelle apparence de l'écran, et demande à X de l'afficher.

On devine ainsi qu'il serait plus simple que le même programme soit en charge de la composition de l'écran et de la réception des évènements matériels. C'est la différence architecturale la plus fondamentale entre X et Wayland. Wayland n'est qu'un ensemble de bibliothèques qui simplifient l'écriture d'un compositeur en mesure de communiquer lui même avec le matériel.

Dépannage

«Cannot open display: :0» avec les applications basées sur Electron

Vérifiez ne pas avoir défini la variable GDK_BACKEND=wayland au niveau global (variable d'environnement). Une variable définie de cette façon cassera les application basées sur Electron.

Jeux, Bureau à distance, et Machine virtuelle

Contrairement à Xorg, Wayland n’autorise pas une application à préempter les ressources d'un périphérique (la souris, le clavier). Sous Wayland, il est de la responsabilité du compositeur de confiner la souris à une seule application, et de retransmettre les évènements (comme les raccourcis clavier) au programme qui possède le focus.

Ce comportement impacte le fonctionnement de certaines applications actuelles. Une solution simple consiste à passer par des applications Xorg à travers XWayland. Dans le cas ou ceci n'est pas possible. Vous pouvez vous référer à cet article.

Liens

gollark: The XP is very.
gollark: It's actually quite costly to that because enchanting bad.
gollark: Undergo rotation.
gollark: Can drones do that?
gollark: Besides, you'd need 512.
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.