[image: X11-wayland.webp]
Dans le monde Linux, on entend parler des serveurs graphiques X11 et Wayland depuis longtemps. Mais de quoi s’agit-il exactement ? À quoi sert un serveur graphique ? Quelles sont les promesses de Wayland et pourquoi la migration prend autant de temps ? Nous vous proposons d’y voir plus clair.
Présentons les deux protagonistes de notre sujet. D’un côté, le X Window System. Sa première version date de 1984, en tant que projet développé au sein du MIT. Il a été essentiellement pensé à une époque où l’on trouvait des serveurs informatiques puissants et des clients légers, d’où son appellation de serveur, qui lui est resté.
On le connait mieux aujourd’hui sous son nom de X11. L’appellation vient de la onzième version de X, sortie en 1987. Ce fut la première révision à être considérée comme stable et pleinement opérationnelle. Et oui, techniquement, on utilise cette onzième version depuis 35 ans. Mais dans la pratique, les évolutions ont été continues.
De l’autre côté, on a Wayland. Beaucoup plus récent, le projet a été lancé en 2008 par Kristian Hogsberg, développeur chez Red Hat. Objectif, proposer un protocole moderne et gagnant sur toute la ligne : plus sécurisé, plus efficace et surtout plus simple. Une base neuve, capable d’exploiter beaucoup mieux le matériel qui avait largement évolué et de se débarrasser des vieilles assises de X11.
Qu’est-ce qu’un serveur graphique ?
Penchons-nous maintenant sur ce qu’est un serveur graphique (ou d’affichage), le rôle que tient ce composant et ses principaux attributs.
Commençons par le commencement. Sur un système de type Unix, dès que vous voyez quelque chose s’afficher à l’écran au sein d’une interface graphique, c’est que le serveur d’affichage est impliqué. Ce composant crucial est chargé de dessiner les fenêtres à l’écran et de gérer toutes les interactions qui s’y rapportent, ainsi que la composition de l’ensemble (assemblage des fenêtres). Il est une interface entre l’utilisateur, l’interface et le matériel lié. Il va d’ailleurs plus loin que le seul aspect graphique, puisqu’il s’occupe également des entrées de la souris et du clavier.
Au départ, l’architecture graphique était monolithique. Le serveur d’affichage devait avoir un accès complet, direct et exclusif à la carte graphique. Dans ce contexte, les pilotes – qui gèrent toute l’exploitation du matériel – étaient placés en espace utilisateur, sans accès direct au noyau. Une approche a priori sécurisée, mais qui s’est progressivement révélée peu efficace dans de nombreux scénarios. Toute la logique critique de l’affichage se retrouvait gérée par un composant unique qui embarquait tous les pilotes nécessaires.
Plusieurs composants sont donc apparus avec le temps pour répartir ce fonctionnement et répondre aux problématiques. D’abord le DRM, ou Direct Rendering Manager. En tant que sous-système du noyau Linux, il gère les accès au GPU. Il tient un rôle d’arbitre : il s’occupe avant tout de distribuer les ressources graphiques aux applications, gère la mémoire ainsi que la sécurité. Grâce à lui, les applications ont pu obtenir un accès direct au GPU (sans passer par X) et l’exploiter, avec une hausse majeure des performances.
[image: Fedora-2025-09-12-10-29-30-1024x640.png]
Fedora a été la première distribution majeure à passer sur Wayland par défaut
Quelque part dans le noyau
Le KMS, ou Kernel Mode Setting, est un autre sous-système du noyau Linux. C’est à lui que revient la gestion de la résolution de l’écran, sa fréquence de rafraichissement, la profondeur des couleurs, etc. Il a permis de déplacer la logique de la « configuration de mode » de l’espace utilisateurs vers le noyau, avec plusieurs bénéfices importants. C’est grâce au KMS par exemple que la console a pu basculer en haute résolution dès le démarrage de la machine.
DRM et KMS s’utilisent à travers une bibliothèque (libdrm), qui expose des fonctions standardisées (et documentées) aux applications. L’arrivée de ces deux composants a été une étape majeure, avec une séparation nette entre la logique matérielle de bas niveau et celle d’affichage haut niveau, avec notamment tout l’applicatif, y compris le serveur graphique.
Au-dessus de DRM et KMS, on trouve un autre composant, important lui aussi, mais en espace utilisateur cette fois : Mesa. Si vous utilisez Linux, ce nom vous est peut-être familier. C’est une implémentation open source des API graphiques standard de l’industrie, comme OpenGL et Vulkan.
Prenons un exemple pour schématiser le fonctionnement général. Un jeu a des scènes 3D à faire afficher à l’écran. Il est conçu pour Vulkan et décrit donc ces scènes à l’API correspondante. Ces requêtes sont adressées à Mesa, qui s’occupe de traduire ces requêtes de haut niveau en instructions plus bas niveau, compréhensibles par le matériel. Ces instructions sont alors transmises au pilote DRM du noyau, qui les exécute sur le GPU.
Pourquoi un successeur à X11 ?
Si l’on se replace dans le contexte des jeunes années de X11, il n’était question que d’architecture client-serveur. Dans cette optique, X11 avait d’ailleurs été développé pour le réseau, avec certaines caractéristiques spécifiques. Par exemple, nulle obligation que le serveur X fonctionne sur la machine la plus puissante. Selon les cas, on pouvait faire tourner le serveur X sur un poste léger, et le client X sur un gros serveur.
Ce fonctionnement, ainsi que d’autres aspects tenant à des choix faits il y a plusieurs décennies, ont alimenté la réflexion qui a mené à Wayland. En matière d’efficacité d’abord, ce modèle client-serveur devenait un poids sur les machines plus récentes : le serveur et le client étant situés sur le même ordinateur, tout ce qui touche au réseau est inutile dans de nombreux cas. Les couches de communication et de multiples étapes intermédiaires (notamment codage/décodage) devenaient superflues et se payaient par une latence.
En outre, X11 est un vieux projet, avec une partie héritée dans le code de plus en plus importante. Ses capacités ont été augmentées par d’innombrables ajouts, extensions et patchs en une énorme base plus difficile à entretenir. Un immense patchwork qui a rendu les développements plus complexes au fur et à mesure que les besoins changeaient.
L’ensemble a abouti à un pipeline de traitement peu adapté aux applications et matériels modernes. Il n’a par exemple pas été conçu pour des écrans avec de hautes fréquences de rafraichissement et un rendu sans déchirement (tear-free). Pour ce dernier problème, il a fallu recourir à des solutions spécifiques et complexes, avec une synchronisation verticale forcée, qui a introduit elle-même de nouveaux problèmes dans certaines situations, comme un « bégaiement » de l’image (le fameux stuterring).
[image: image-95-1024x576.png]
Ubuntu 25.10 avec GNOME 49 intègre toujours X11
Que propose Wayland ?
L’idée qui a mené à Wayland était de proposer un fonctionnement simple, sécurisé et plus efficace. Le tout en partant d’une page blanche.
Le plus gros changement réside dans la conception : le serveur d’affichage, le gestionnaire de fenêtres et le compositeur sont en fait un seul et même processus, le compositeur Wayland. Dans ce modèle, le compositeur gère l’intégralité des opérations liées à l’affichage. Il reçoit ainsi les évènements d’entrées (clavier, souris, tablettes graphiques…), gère les surfaces (fenêtres), assemble l’image finale et communique avec le noyau (via DRM et KMS, toujours là) pour afficher l’ensemble. C’est vers le compositeur Wayland que les applications se tournent pour présenter un objet à l’écran.
La sécurité est un autre changement radical, puisque Wayland impose une isolation stricte entre les clients, et donc les applications. Ces dernières ne peuvent ainsi voir que leurs propres fenêtres. Elles ne peuvent en outre recevoir les évènements d’entrées que si elles ont le focus, c’est-à-dire quand elles sont au premier plan, pour éviter qu’elles espionnent d’autres applications (ce qui vaut aussi pour les enregistreurs de frappe et les logiciels espions). De plus, elles ne peuvent pas décider où placer les fenêtres, c’est Wayland qui le fait.
L’une des grandes promesses de Wayland, c’est son approche moderne du matériel. De nombreuses caractéristiques sont nativement prises en compte. Beaucoup plus à l’aise avec les configurations multi-écrans, il gère mieux les hautes définitions (HiDPI). Il prend nativement en charge la mise à l’échelle fractionnée (125 ou 150 % par exemple), les taux de rafraichissement différents selon les écrans, les écrans tactiles et les gestes multi-touch.
Wayland est un protocole, pas un logiciel
Wayland est une spécification de protocole, pas un logiciel unique comme l’est X11. Il ne s’agit donc pas d’un composant standardisé auquel tous les autres peuvent se référer en tant que tel. C’est encore une différence fondamentale avec X11, puisque la responsabilité de fournir un environnement de bureau complet est déplacée vers chaque compositeur qui implémente cette spécification Wayland.
Si l’on prend les deux environnements de bureau les plus utilisés, GNOME et KDE, cette responsabilité est confiée respectivement à Mutter et KWin. Et c’est ici que les problèmes peuvent commencer, car cette approche engendre une fragmentation. Si vous souhaitez développer une application, il ne suffit pas en effet de dire « elle est compatible Wayland ». Il faut s’assurer qu’elle fonctionne correctement avec Mutter, KWin ou n’importe quel compositeur qui a implémenté Wayland. Or, ces implémentations ne sont pas identiques. Il existe des variations autour des extensions présentes et des subtilités dans la mise en application.
Ce qui nous fait entrer de plain-pied dans la grande question : pourquoi l’adoption de Wayland est-elle aussi lente ?
Un nombre incalculable de problèmes
Dire que la transition de X11 vers Wayland a été complexe relève de l’euphémisme. On savait qu’une rupture aussi radicale dans l’approche n’aurait pas que de joyeuses conséquences. En outre, Wayland a ses propres problèmes, et certaines promesses n’ont qu’en partie été tenues.
Le modèle de sécurité entraine ainsi une grande cassure. L’isolation stricte des clients a des conséquences majeures sur les fonctionnalités, notamment d’accessibilité. Les lecteurs d’écran, à destination des personnes aveugles ou malvoyantes, ne pouvaient plus fonctionner. Il en allait de même avec les outils de partage ou d’enregistrement d’écran (Discord, OBS…), de bureau à distance (VNC, RDP…), les raccourcis clavier globaux ou encore les outils d’automatisation (Autokey…).
Il a donc fallu tout repenser. C’est là qu’entrent en piste deux composants clés : PipeWire pour l’audio et les portails de bureau XDG pour le graphique. Ces derniers sont des API de haut niveau auxquelles les applications s’adressent pour demander certaines actions, comme accéder à l’écran pour le partager. Ils agissent comme des portails sécurisés pour concentrer les demandes. Le traitement lui-même est confié à PipeWire. Celui-ci a été pensé initialement comme le successeur de PulseAudio et de Jack, mais son rôle a été étendu pour gérer les flux vidéo.
Si PipeWire est un framework utilisable en tant que tel, les portails XDG dépendent des environnements. On trouve par exemple xdg-desktop-portal-kde et xdg-desktop-portal-gnome, respectivement pour KDE et GNOME. Il faut donc que les applications fassent appel à ces composants pour faire leurs demandes.
Cette immense cassure explique déjà en bonne partie pourquoi il a fallu des années avant que des fonctions considérées comme élémentaires avec X11 soient disponibles avec Wayland. Embrayons avec un autre facteur-clé de cette lenteur dans la transition : NVIDIA.
NVIDIA, l’élément (très) perturbateur
Si vous êtes utilisateur de Linux, vous savez peut-être que posséder un GPU NVIDIA peut être synonyme de galère, notamment à cause des pilotes. Pour une expérience complète, notamment avec les jeux, il est presque obligatoire d’utiliser le pilote propriétaire fourni par l’entreprise. Problème, celle-ci avait une vision précise de comment les choses devaient être organisées.
Historiquement, la pile graphique Linux s’est organisée autour d’une API : Generic Buffer Manager, ou GBM. Cette interface est responsable de l’allocation et de la gestion des tampons graphiques en mémoire. NVIDIA ne l’a pas entendu de cette oreille et a tenté de pousser sa propre API, EGLStreams. À l’implémentation des compositeurs Wayland, il fallait ainsi ajouter des chemins de traitement dédiés à NVIDIA. Ce code spécifique a été source de retards et de bugs. Après des années de pression de la communauté, l’entreprise a finalement cédé et implémenté le support de GBM.
Ce n’était pas le seul problème. Un autre conflit existe et n’est toujours pas résolu : la bataille entre les synchronisations implicite et explicite. Historiquement (encore une fois), la synchronisation sous Linux est implicite : le pilote du noyau s’en charge et s’assure qu’une opération de lecture sur un tampon graphique ne se déclenche qu’une fois que l’opération d’écriture précédente est finie. Ce modèle a le gros avantage de simplifier le développement d’applications, mais il peut manquer d’efficacité, car le pilote ne connait pas les « intentions » de l’application. AMD et Intel ont bâti leurs pilotes open source sur ce modèle.
Dans la synchronisation explicite, c’est à l’application ou l’API graphique (comme Vulkan) d’indiquer quand une opération est terminée. La méthode a pour inconvénient de reporter cette charge sur les développeurs d’applications, dont la tâche devient plus complexe. En revanche, le parallélisme et les performances sont meilleurs. NVIDIA a choisi ce modèle pour son pilote open source. La solution n’est apparue qu’au printemps 2024 sous la forme d’un protocole de synchronisation explicite pour Wayland.
Linus Torvalds avait eu en 2012 sa façon bien à lui de dire tout le bien qu’il pensait de NVIDIA avec un doigt d’honneur devenu célèbre. Si le problème à l’époque n’était pas directement lié (il était alors question des puces Tegra), il préfigurait ce qu’allait être la relation entre l’entreprise et le monde du libre pour de nombreuses années.
XWayland, le pont entre les deux mondes
Vous avez peut-être là aussi croisé ce nom : XWayland. Ce composant a vite eu un rôle critique au sein des distributions Linux, car il assure la compatibilité en permettant aux applications X11 de fonctionner sur Wayland. Comment ? En fournissant un serveur X11 complet, qui s’exécute comme un client Wayland.
On comprend vite l’intérêt. Toutes les applications ne sont pas encore prêtes pour Wayland et certaines ne fonctionnent qu’avec X11. Lorsqu’une telle application est lancée, elle se connecte à XWayland, qui traduit les requêtes pour les envoyer au compositeur Wayland.
Il n’est donc pas question d’une simple couche d’émulation temporaire, mais bien d’un composant en soi, devenu la pierre angulaire de toute la stratégie de transition. Elle a cependant des limites, car ce modèle encapsulé peut créer des incompatibilités dans la communication entre les applications X11 et Wayland, sur des opérations très basiques comme le copier-coller ou le glisser-déposer. Ses performances sont moins bonnes, certaines fonctions peuvent être inaccessibles et des problèmes de sécurité spécifiques à X11 sont toujours là.
La transition étant loin d’être terminée, XWayland restera en place encore longtemps. C’est d’ailleurs à cause de son importance cruciale que les grandes décisions actuelles de transition plus complète vers Wayland épargnent XWayland. Par exemple, l’équipe de développement de GNOME a annoncé que la version 49 de l’environnement commencerait à supprimer tout le code lié à X11, mais cette décision ne s’étend pas à XWayland. L’équipe a depuis changé d’avis, se laissant un peu plus de temps pour supprimer ce code.
Notez que de nombreuses distributions utilisent des sessions Wayland par défaut depuis plusieurs années. Certaines permettent cependant un autre type de session depuis l’écran de connexion, dont X11. Avec le retrait du code, cette capacité disparaitra complètement.
[image: Debian-2025-09-12-10-18-11-1024x640.png]
Debian 13 permet toujours de choisir une session X11
Et aujourd’hui alors ?
Aujourd’hui, la transition est irréversible. Depuis l’année dernière notamment, des étapes majeures se sont enchainées, aboutissant aux décisions récentes autour de Wayland et du gommage progressif de X11 dans le code. XWayland va rester en place et assurer la compatibilité des applications n’ayant pas fait encore le voyage. Les raisons peuvent être multiples, comme un manque de moyens face à l’ampleur du travail, ou un abandon partiel ou complet du projet. Qu’il s’agisse de Fedora, Ubuntu ou encore Red Hat, tous ont annoncé des plans pour déprécier X11 plus ou moins rapidement.
X11 est désormais dans un quasi-état de maintenance. Très peu de nouveautés sont ajoutées, car l’essentiel du travail se fait sur Wayland. D’ailleurs, une bonne partie des personnes qui travaillaient sur X11 sont aujourd’hui sur Wayland.
Mais la transition aura été particulièrement longue. L’explication est multifactorielle, comme on l’a vu : NVIDIA a été un élément perturbateur majeur, le modèle de sécurité de Wayland a nécessité la réécriture complète de nombreux éléments et il a fallu du temps pour que des fonctions élémentaires soient de retour. De manière générale, si Wayland n’est pas exempt de défauts, il représente définitivement l’avenir de la pile graphique sur Linux. Et s’il doit durer aussi longtemps que X11, il restera en place plusieurs décennies.
La plupart des gros problèmes liés à Wayland sont aujourd’hui réglés, le dernier gros point à traiter étant la gestion de la synchronisation explicite au sein des compositeurs. Les prochaines années seront consacrées au polissage, à l’accompagnement des applications « récalcitrantes » ou encore à la création de fonctions manquantes, comme une véritable suite d’outils pour l’accessibilité. Il faudra également que les extensions les plus courantes de Wayland continuent leur standardisation afin de gommer les différences entre les environnements de bureau.
Source : next.ink
