Sommaire
Tout d'abord, il faut savoir que Kristian Høgsberg, le créateur de Wayland, a été développeur X ; il a contribué à ajouter les compositeurs 3D à AIGLX, alors qu'il travaillait pour RedHat. Il commençait alors à développer Wayland pendant son temps libre en 2008. Il n'est donc pas opposé à X mais pense que son architecture n'est plus adaptée à l'usage qu'on en fait actuellement.
Pour la petite histoire, Wayland vient de la ville Wayland, MA situé aux États-Unis dans le Massachusetts. Kristian Høgsberg traversait cette ville quand les principes sous-jacents de Wayland ont été définis.
Principes de fonctionnement de Wayland
Le projet MeeGo, développé principalement par Intel, a été le premier à déclarer vouloir utiliser Wayland à la place de X.Org pour son système d'exploitation. Kristian Høgsberg travaille dorénavant à plein temps sur Wayland chez Intel. Wayland est une nouvelle architecture pour un serveur d'affichage. Il intègre un serveur, un gestionnaire de fenêtre et un compositeur.
Il n'y a pas d'API pour le rendering, les applications écrivent directement dans un buffer. Le compositeur est l'application qui se charge de regrouper les différents buffers graphiques des applications en un seul buffer affichable sur un écran (par exemple, il faut que la fenêtre au premier plan soit entièrement visible et non pas cachée par un bout d'une autre fenêtre).
Dans le monde Linux, les compositeurs ont été popularisés par les bureaux en cube 3D ou les fenêtres en flammes à la sauce Compiz. En dehors de cela, ils apportent une véritable amélioration : déplacer ou redimensionner une fenêtre ne provoque plus un clignotement de celle-ci (risque d'épilepsie réduit de 50 % !), c'est-à-dire qu'ils évitent une phase intermédiaire durant laquelle la fenêtre est blanche puis redessinée.
Le serveur d'affichage de Wayland est en fait le compositeur et les applications dialoguent directement avec lui. Le but n'est pas vraiment de gagner des performances mais d'avoir une architecture simple et plus adaptée à l'utilisation actuelle.
Avec X :
Avec Wayland :
(Schémas tirés de la documentation de Wayland)
Avec Wayland, c'est aussi le compositeur qui va lire les informations des périphériques d'entrée et les distribuer aux applications concernées. Wayland est donc le protocole qui va permettre aux applications d'envoyer leur buffer au compositeur et au compositeur d'envoyer les événements d'entrée aux applications.
Pourquoi X n'est plus adapté
X dispose d'une API pour le rendering qui n'est plus utilisée par les applications car elles génèrent l'image à afficher en local et l'envoient toute prête au serveur graphique. Par exemple, X peut faire du rendu de police mais aucune application ne l'utilise aujourd'hui. [Commentaire: cet exemple est discutable: l'ancien rendu de police d'X n'est plus utilisé mais avec l'extension XRender les applications peuvent envoyer sur le serveur une image contenant leur fonte (GlyphSet) ce qui permet d'afficher du texte avec une bande passante réduite par rapport à l'envoi de l'image du texte entre un client et le compositeur.]
De plus, X possède un système complexe de sous-fenêtres, tombé en désuétude, qui était utilisé pour éviter de repeindre toute la fenêtre lors d'une modification ou pour gérer les événements du curseur (il existe une extension XDamage pour faire cela maintenant). Sa maintenance est un poids mort car peu nombreux sont ceux qui en maîtrisent les arcanes.
L'interface des pilotes n'est pas plus adaptée. L'architecture est prévue pour un pilote par périphérique alors qu'evdev¹ (géré par le noyau) est quasiment le seul utilisé.
Au final la tâche principale assurée par X est la distribution les événements d'entrée vers les applications concernées, mais comme il ignore quelle fenêtre doit recevoir l'information — rôle délégué au compositeur — il ne peut pas le faire correctement.
Dans ces conditions, l'argument principal pour l'abandon de X réside dans l'usage très partiel qu'en font les applications, tellement faible qu'il ne justifie pas les efforts nécessaires pour maintenir les nombreuses autres fonctionnalités inutilisées.
X "works" for us today, because we've built a different display system on top of it.
X "marche" pour nous aujourd'hui, parce qu'on a construit un système d'affichage différent par dessus.
(citation tirée des slides la conférence Wayland au Fosdem)
¹ : Evdev est un pilote générique pour les différents systèmes d'entrée (claviers, souris…) gérés par le noyau Linux. Il s'occupe d'extraire les informations des pilotes spécifiques aux divers matériels pour les présenter sous une forme générique.
Déroulement de la migration
Pour le serveur
Comme différents composants de X ont été éclatés un peu partout, les compositeurs vont pouvoir les réutiliser : KMS pour l'affichage, EGL/GLES2² pour le rendu et lire les événements d'entrée via evdev.
Il existe déjà un compositeur de référence pour Wayland qui répond au doux nom de Weston : il fait moins de 10 000 lignes de code et fait tourner la présentation de Kristian høgsberg au Fosdem. Néanmoins il est possible d'utiliser les compositeurs de X (mutter, kwin, enlightenment…) avec Wayland, moyennant des adaptations.
Pour les clients
La plupart des applications passent par l'intermédiaire de bibliothèque graphiques (GTK, Qt, EFL, SDL…) pour accéder aux fonctionnalités de X, il suffit donc de porter ces bibliothèques. Il y a cependant quelques différences avec X :
- Les applications ne peuvent pas monopoliser les touches. Avec X, une application pouvait demander à ce qu'elle soit la seule à recevoir les notifications du clavier, ce n'est pas possible dans Wayland. Mais les développeurs se sont rendus compte que c'était très peu utilisé, le cas d'utilisation principal est le menu déroulant car les applications veulent le faire disparaître si on clique ailleurs. Les développeurs préfèrent que l'application notifie le serveur que c'est un menu déroulant et le gérer en conséquence ;
- Les décorations de fenêtre sont à la charge des clients plutôt qu'au serveur³;
- Les applications ne peuvent recevoir que les coordonnées relatives dans la fenêtre et non pas les coordonnées globales sur l'écran. Le but est de résoudre le problème qui se pose lorsque le compositeur effectue une transformation sur la fenêtre. Par exemple, il peut lui faire subir une rotation de 45° ou l'appliquer sur une sphère. Encore une fois, cela peut poser des problèmes lors de l'affichage de menus qui pourraient sortir de l'écran mais le problème est connu et les développeurs réfléchissent à une solution. Cela posera problème si X est utilisé en tant que client de Wayland.
² : EGL et GLES2 sont une surcouche à OpenGL qui permettent d'accélérer le rendu.
³ : Il s'agit du comportement de Weston, mais pour les autres compositeurs le choix pourrait être différent (KDE a prévu de faire son propre compositeur http://blog.martin-graesslin.com/blog/2011/08/kwin-at-desktop-summit/)
Pour les pilotes
Weston, le compositeur de référence, a besoin de KMS et d'une pile EGL qui sont fournis par Linux et Mesa donc les pilotes basés sur Mesa et KMS.
Concrètement, les pilotes libre pour les cartes Intel, AMD et nVidia, fonctionnent avec Wayland. Pour les pilotes propriétaires, cela reste une inconnue.
Planning
Une première version de Wayland (0.85) est sortie le 9 février 2012. Kristian Høgsberg a fait part des buts à atteindre pour sortir une version 1.0, prévue fin 2012, comme la prise en charge des GPU multiples et l'affichage déporté.
Cette version assurera une stabilité des API (pas de retrait ni de modification de fonction) mais devrait sans doute nécessiter des ajouts. En parallèle, les compositeurs et les bibliothèques écrits originellement pour X vont continuer leur mutation pour pouvoir utiliser pleinement Wayland.
Après cette sortie, Wayland pourra être sérieusement intégré dans nos distributions GNU/Linux favorites.
L'utilisation éventuelle de Wayland par les *BSD serait plus difficile : Wayland utilise des APIs présentes uniquement dans Linux actuellement.
