Ce que Wayland n’est pas
Ce n’est pas un programme, on ne lance pas Wayland pour afficher des fenêtres.
Ce n’est pas un serveur, ça ne s'exécute pas en tâche de fond.
Ce n’est pas un gestionnaire de fenêtres… et non… non plus…
Qu’est-ce que Wayland, alors ?
C’est un protocole. Une façon de communiquer ENTRE programmes.
Un protocole qui sert à:
- Échanger des éléments graphiques (fenêtres) entre un programme maître et des programmes esclaves via des espaces mémoire partagés.
- Développer des programmes qui affichent des fenêtres, qu’on appelle compositeur.
- Développer la partie graphique (bas niveau) des applications esclaves (ou clientes, si vous préférez).
Architecture générale (source)
1. Le noyau transmet un événement au compositeur.
2. Le compositeur transmet à l'application.
3. L'application modifie son apparence.
4. Le compositeur compose l'image a l'écran.
Ce protocole ‘aide’ au développement d’applications grâce à la façon dont il est décrit.
Le protocole est décrit en XML dans un fichier accessible de tous. Il est utilisé pour compiler le compositeur et les applications. L’outil ‘wayland-scanner’ l’utilise pour générer du code C. Ce code est ensuite utilisé pour faciliter le travail de développement des clients et compositeurs.
Le compositeur prendra en charge OpenGL, Vulkan et consorts de la même façon que n’importe quelle application, c'est à dire via le kernel grâce aux bibliothèques DRM et mesa. Ces technologies servent à intégrer directement les éléments d’affichage en provenance des clients.
Idem pour les périphériques d’acquisition, tels que clavier/souris, que l’on nommera ‘seat’ pour 'siège d’utilisateur’, ‘poste de travail utilisateur’. C’est le compositeur qui se chargera de transmettre aux clients les événements des périphériques, en utilisant le protocole Wayland.
Pourquoi passer à Wayland?
Wayland est différent de X11.
X11 est aussi un protocole, mais utilisé uniquement par le serveur Xorg. C’est un programme administrateur qui gère les pilotes, l'écran, les périphériques d’acquisition, etc.
Ce serveur (car c’en est un, lui), ne prend pas directement en charge l’affichage des fenêtres, il ‘ouvre’ une surface d’affichage à l'écran pour que d’autres programmes y gèrent d’autres surfaces pour y afficher la liste de vos photos de Noël 1992. Ces autres programmes, appelés "window managers" sont des environnements tels que KDE, Gnome, LXDE ou FluxBox
Les compositeurs Wayland présentent l’avantage d'être plus légers et plus agiles à mettre en place puisqu’ils ne nécessitent pas d’élévation de privilèges pour fonctionner. Un simple utilisateur peut les démarrer, réduisant leur empreinte mémoire et les vulnérabilités potentielles.
C’est un gros atout dans le monde de l'embarqué.
Comment ‘passer à Wayland’
C’est une vaste question, même s’il est aisé de mettre en place un compositeur, ‘utiliser Wayland’ revient généralement à installer un compositeur comme Sway, Weston ou bien d’autres.
Cependant, le problème vient bien souvent des applications, qui doivent supporter ce protocole, c'est-à-dire qu’elles doivent être compilées avec le support de Wayland.
Pour les applications basées sur GTK, Qt ou un autre framework graphique populaire similaire, c'est entièrement géré par les bibliothèques et vos applications supporteront Wayland sans même avoir à les recompiler.
Pour les autres, un programme existe pour permettre aux applications X11 de communiquer avec un compositeur Wayland. Il s'agit de Xwayland.
Xwayland, le passe plat
Xwayland est un proxy qui ouvre une socket X11 (serveur), et une socket Wayland (cliente) connectée au compositeur. Le tout est de bien indiquer aux applications X11 de se connecter à la socket X11 de Xwayland.
Architecture avec Xwayland (source)
1. Le noyau transmet un événement au compositeur.
2. Le compositeur transmet à Xwayland.
3. Xwayland traduit l'événement pour le client X11.
4. Le client X11 modifie son apparence.
5. Xwayland transmet la nouvelle image au compositeur.
6. Le compositeur compose l'image a l'écran.
Fort heureusement, l’usage de Xwayland est intégré dans le compositeur et est généralement transparent pour l’utilisateur.
Comment ça marche, plus en détail
Le protocole
Dans les grandes lignes, le protocole permet de partager des ‘surfaces’ (wl_surface) via des espaces de mémoire partagée (wl_shm).
L’application demande au compositeur de créer ces surfaces, elle les modifie (damage) et notifie le compositeur que les images (surfaces) ont été mises à jour (commit).
Le compositeur transmet les événements (ex: clavier/souris) à l’application, qui acquitte le message puis réagit en modifiant l’image, et ainsi va la vie.
Le compositeur
C’est le programme qui centralise les surfaces pour les afficher, ou en faire autre chose (par exemple les envoyer via le protocole VNC).
Usuellement, on imagine le compositeur comme le gestionnaire de fenêtres, comme Sway, Gnome et consorts.
C’est vrai à plus d’un titre, mais le compositeur pourrait aussi bien centraliser les surfaces de ces applications, et s’en servir pour générer un flux vidéo qui partirait sur le réseau, ou s’afficher dans la fenêtre d’un autre compositeur, ou pourquoi pas dans un driver d'écran led géant d’une forme exotique sur un plateau télévisé.
La socket
C’est le point d'entrée d’un compositeur. A son démarrage le compositeur va ouvrir un fichier (puisque tout est fichier, sous Linux) qui sera une socket de communication pour les applications.
C’est un point d'entrée important car, le compositeur n'étant pas exclusif à un système, on peut avoir plusieurs compositeurs sur un système et ainsi choisir où afficher chaque application.
Les clients
J’imagine qu'à cet instant, vous avez lu l’article. Alors, je vous retourne la question? Qu'est ce qu'un client?
(¡zǝʌᴉns snoʌ ´oʌɐɹq ´uoᴉʇɐɔᴉןddɐ ǝun : ǝsuodǝɹ)
Et comment sait-on où elle va s’afficher?
Sur le compositeur, derrière la socket qu’elle aura ouverte au démarrage de l’application. Cela se configure en positionnant la variable d'environnement $WAYLAND_DISPLAY
Les extensions
Là, on arrive dans un sujet un peu plus technique. Je vous parlais plus haut du protocole décrit dans un XML.
Les extensions sont des ajouts au protocole, décrit, eux aussi dans un XML, et mises à la disposition de ‘wayland-scanner’ afin d’ajouter des fonctionnalités au protocole.
L’extension la plus usitée est XDG, qui ajoute, entre autres, des API de manipulation des surfaces (déplacer, changer de taille).
D’autres existent et sont déjà bien répandues, mais peut-être feront-elles l’objet d’un autre article.
Conclusion
Les idées reçues sur Wayland reposent sur notre connaissance actuelle des environnements graphiques dont nous avons l’usage sous Linux.
Dans les faits Wayland s'éloigne un peu de ces idées en proposant une simplification des interactions entre le système et les périphériques utilisateurs.
Beaucoup de frameworks graphiques proposent déjà des bibliothèques compatibles avec Wayland.
Pour les développeurs, Wayland devrait apparaître comme un outil très souple pour la création de systèmes embarqués à écran.
En espérant vous avoir diverti