X.Org est mort, vive Wayland!

Wayland logoEh oui les amis, ça y est, le jour tant attendu est arrivé : Wayland 1.0 est enfin là!

À ce jour, sur tous les ordinateurs de bureau et portables sous GNU/Linux, BSD ou Solaris de la planète, l’interface graphique — que ce soit KDE, GNOME ou autre — est gérée par X Window System ou X11, dont X.Org est une implémentation (dérivée de XFree86).

Fait tout aussi notable : dans le monde mobile (Android) ou de l’embarqué où GNU/Linux est largement diffusé, X.Org est la plupart du temps absent.

X a été conçu au MIT en 1984 — il y a presque 30 ans! —, sa version 11 datant, elle, de 1987, ce qui est très vieux pour du code gérant du matériel ayant subi de nombreuses (r)évolutions, avec pour corollaire que X.Org est devenu très difficile à maintenir.

De plus, avec l’avènement des compositeurs (permettant des effets de transparence, d’ombre portée, etc.), le fonctionnement de X.Org pour la gestion graphique ne semble plus optimal, car il constitue une étape supplémentaire entre l’application et le compositeur ainsi qu’entre le compositeur et le matériel.

Plusieurs tentatives pour remplacer X ont eu lieu : Y Window System, Fresco/Berlin… Aucune n’a rencontré le succès escompté.

En 2008, le Danois Kristian Høgsberg a décidé de créer un nouveau serveur d’affichage, à la fois plus moderne et plus simple à maintenir : le projet Wayland était né.

C’est donc finalement le W de Wayland qui succèdera à X!

Pour se donner une petite idée de leurs différences, l’interface de programmation (API) de Wayland est environ 15 fois plus petite que celle de X…

Du côté utilisateur, on nous promet quelques bénéfices immédiats : une plus grande fluidité, un affichage sans cisaillements (tear free) quand la décoration est gérée par le client…
Notons enfin que Wayland n’est pas développé contre X.Org, mais avec le plein appui des développeurs de ce dernier qui voient bien l’intérêt de simplifier la maintenance. D’ailleurs, la Fondation X.Org vient de réviser ses statuts en incluant Wayland dans les logiciels qu’elle soutient.

Participants à la rédaction de cette dépêche : reno, antistress, Xavier Claude, Davy Defaud, Patrick_g, Benoît.

Bref rappel de l’architecture de Wayland

Wayland est construit au sommet des briques récemment ajoutées à la pile graphique de Linux : DRI 2 (accès direct, sans passer par le serveur X, au processeur graphique pour les applications), GEM (gestionnaire de mémoire graphique commun aux pilotes, utilisé par KMS) et KMS (gestion de la résolution et du nombre de couleurs par le noyau, au lieu du serveur graphique), tous deux utilisés par l’intermédiaire d’EGL.

Le fait que Wayland s’appuie sur KMS entraîne une première conséquence forte : seuls les pilotes libres sont actuellement à même de faire tourner Wayland!

Wayland est le nom du projet et du protocole d’affichage; le projet contient plusieurs parties :

  • une bibliothèque implémentant ce protocole, elle est utilisé par les clients et par le serveur pour communiquer;
  • un serveur d’affichage de référence : Weston;
  • des exemples de clients.

Au début, il était prévu que Weston soit uniquement un prototype utilisé pour tester le protocole, mais il est vraisemblable que Weston sera utilisé en tant que tel dans l’embarqué.

Un serveur Wayland joue à la fois le rôle de compositeur, de gestionnaire de fenêtres et de serveur d’affichage.

Le fonctionnement de Wayland est le suivant : le serveur envoie les événements d’entrée (souris, clavier…) au client concerné. Le client traite l’événement et dessine localement dans un tampon puis envoie la référence du tampon modifié au serveur. Le serveur rassemble les différents tampons pour dessiner l’image finale qui sera affichée. Il est important que le serveur soit le compositeur et aussi le gestionnaire de fenêtres, pour déterminer quelle partie de chaque tampon il doit afficher et à qui envoyer les événements d’entrée.

Débats liés à Wayland

Si Wayland a été globalement bien accepté et souvent salué (par rapport à la fronde que soulève systemd, par exemple… +300 points au trollomètre), il a aussi rencontré des oppositions liées à plusieurs problèmes potentiels :

  • la perte de la compatibilité avec X;
  • la perte de la transparence réseau pour des applications natives Wayland;
  • l’homogénéité de l’affichage des fenêtres : avec Weston, il est prévu que ce soit les clients qui dessinent eux mêmes leurs décorations.

Ces sujets sont détaillés ci dessous.

Compatibilité avec X : XWayland

La compatibilité avec X a été un problème sur lequel les développeurs de Wayland ont travaillé très tôt, en fournissant la possibilité d’avoir un serveur X tournant au dessus de Wayland : c’est tout le but de XWayland (lire les explications détaillées en anglais ici).

Le bonus étant qu’une application écrite pour X tournant sur Wayland avec la couche de compatibilité devrait bénéficier de certaines caractéristiques de la nouvelle infrastructure et finalement mieux tourner que nativement sous X.

Transparence réseau

La transparence réseau pour les applications natives Wayland avait été laissée de côté dans un premier temps, mais ça a évolué.

Notons que l’utilisation du réseau par Wayland pourra être différente de celle de X11 :

  1. le nombre de RTT nécessaire : Kristian Høgsberg a dit qu’il avait fait très attention à avoir un protocole asynchrone minimisant les allers retours entre les clients et le serveur*. Ce point pourrait être donc meilleur qu’avec X. Pour rappel, NX avait été créé en grande partie pour améliorer cet aspect de X;
  2. la bande passante utilisée : là, Wayland ne sera pas forcément bon par rapport à X, car ce sont uniquement des tampons qui sont envoyés, contrairement à X qui peut envoyer des tampons, mais aussi des commandes de dessin. À suivre, donc.

(*) : Cependant, il a précisé qu’il n’avait pas fait de tests en simulant une forte latence.

La décoration des fenêtres par les clients

En fait, la décoration des fenêtres par les clients est une des caractéristiques du serveur d’affichage Weston, pas du protocole Wayland : les développeurs de KDE ont d’ailleurs prévu que ce soit le serveur d’affichage qui affiche les décorations des fenêtres.

En dehors du fait de savoir qui affiche les décorations, notons qu’à l’heure actuelle la question de la cohérence graphique se pose déjà quand on fait tourner une application GNOME sous KDE et vice versa, donc ce n’est pas vraiment nouveau.

Différences avec X.Org

  1. Comme nous l’avons écrit plus haut, Wayland permet juste de passer des images (des tampons) entre les clients et le serveur, il n’a donc pas de commandes de dessin comme X. En simplifiant, on peut considérer que Wayland c’est l’extension DRI 2 de X (que l’on doit d’ailleurs à un certain Kristian Høgsberg…).
  2. Wayland peut fournir une notification pour prévenir quand l’image fournie a été affichée, c’est ce qui doit permettre de faire des animations fluides.
  3. Avec Wayland, les applications ne savent pas où le serveur d’affichage met ses fenêtres : pas de coordonnées absolues dans le protocole.
  4. X.Org est implémenté par tous les UNIX, mais Wayland utilise des briques logicielles uniquement disponibles sur Linux actuellement (principalement KMS, nous revenons sur ce point un peu plus loin).

Adaptation des bibliothèques graphiques existantes

Les bibliothèques graphiques Clutter, EFL (Enlightenment Foundation Libraries), GTK+, Qt et SDL (Simple DirectMedia Layer) sont en cours de portage sur Wayland, avec Clutter et EFL qui sont prêts ou quasiment, et GTK+ (le portage est presque complet avec la version 3.4.1), Qt (il faudra la future version 5) et SDL qui sont un peu derrière. Ces portages devraient s’accélérer à présent que l’API de Wayland est stabilisée.

Quant aux applications elles mêmes, celles utilisant GTK+ devraient logiquement être prêtes avant celles utilisant Qt, pour la simple raison que GTK+ 3 est là depuis le 10 février 2011 quand Qt 5 n’est pas encore sorti. Théoriquement une application utilisant GTK+ 3 et n’appelant pas directement Xlib devrait être parée pour Wayland.

Mesa va rapidement connaître une légère mise à jour pour intégrer les dernières modifications du projet, passant en version 9.0.1.

VA-API dans sa dernière version (1.1.0) est censée également être au point pour Wayland.

Propos finaux

Il n’y a pas que Linux dans la vie!

Une question importante se pose dès lors que Wayland se veut le remplaçant de X.Org : pourra t’il — comme X.Org — bénéficier aux autres Unices (BSD…)?
La logique de Wayland ne s’y oppose pas, mais son implémentation actuelle le permet elle?

Répondre à cette question implique de regarder si les briques sur lesquelles repose Wayland sont portables ou portées sur les autres systèmes accueillant actuellement X.Org.

KMS obligatoire

FreeBSD est relativement avancé en la matière, avec les portages de GEM et KMS en cours pour les puces Intel, qui devraient se concrétiser avec la version 10 du projet (lire ici, ici et là). KMS pour puces NVIDIA et AMD prendra un peu plus de temps (les pilotes libres correspondants utilisent TTM au lieu de GEM).

Ce travail bénéficie directement à DragonFly BSD où les développements semblent en revanche se concentrer sur les puces AMD pour le moment (lire ici).

Solaris aurait déjà porté KMS pour puces Intel (lire ici).

À noter qu’une réécriture partielle de KMS est prévue par Intel pour la prochaine version 3.7 de Linux, qui devra être transposée dans les portages sus-évoqués…

udev, une dépendance facultative

udev était requis par Weston pour gérer les périphériques envoyant des évènements par evdev (udev et evdev étant spécifiques à GNU/Linux).
Le portage de Wayland sur Android (en cours de réalisation par Pekka Paalanen) a eu pour effet de supprimer la dépendance obligatoire à udev. Ainsi, udev reste une dépendance de Weston sous GNU/Linux, mais pas sous Android.
Si Weston utilise toujours evdev, le remplacer par un système équivalent sur un noyau autre que Linux ne devrait pas être trop difficile semble t’il.

L’architecture de Wayland elle même est indépendante de ces questions.

systemd? Pas indispensable

L’architecture de Wayland utilise la variable d’environnement XDG_RUNTIME_DIR que systemd implémente actuellement sous GNU/Linux. systemd lui même ne sera pas requis si cette variable est implémentée d’une autre manière sur le système cible.

Tout ça c’est bien beau, mais ça arrive quand chez nous?

Comme le souligne Kristian Høgsberg lui même, et contrairement à ce que laisse entendre le titre tapageur de la dépêche, atteindre la version 1.0 ne signifie pas que Wayland va magiquement et instantanément remplacer X.Org dans toutes les distributions.

Wayland va certainement continuer de mûrir un peu et être testé un peu plus sérieusement (c. à d. à plus grande échelle) avant d’être proposé par défaut dans nos distributions.

En attendant, des CD autonomes (live CDs) sont à votre disposition pour vous faire une idée sans altérer votre système (Rebecca Black Linux ou Fedora, par exemple).

Consultez la source | Article initialement publié sur Linuxfr.org
sous licence Creative Commons By-Sa | Auteur : Nÿco |

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*