YServer 1.7 : pendant que Wayland enterre X11, un développeur le réécrit en Rust avec Claude Code

Réécrire X11 en 2026 : parce que pourquoi faire simple ?

L’histoire de YServer est déjà assez savoureuse. À l’heure où la majorité de l’écosystème Linux investit dans Wayland, Jos Dehaes développe un nouveau serveur X11 écrit entièrement en Rust . Ce n’est ni un fork de X.Org, ni une couche XWayland placée au-dessus de Wayland : YServer implémente directement le protocole X11 et pilote lui-même le matériel graphique via DRM/KMS et Vulkan. Son objectif n’est toutefois pas de reproduire quarante années de compatibilité X.Org à l’identique. Le projet élimine volontairement des éléments considérés comme historiques — anciens visuels non TrueColor, GLX indirect, ABI DDX pour les vieux pilotes ou clients avec ordre des octets inversé — afin de ne conserver que le contrat X11 dont les applications modernes GTK, Qt, SDL, Electron ou les environnements de bureau ont réellement besoin.

Cette démarche rend le projet assez différent d’un hypothétique « Xorg 2 ». YServer possède un cœur volontairement simple, principalement mono-thread, et une architecture pensée autour de Vulkan avec présentation sans tearing. Le serveur prend déjà en charge une longue série d’extensions comme Composite, DRI3, GLX, RANDR, XInput, Xinerama, XKB, Present ou XTEST. Le README officiel indique aujourd’hui que des bureaux complets comme MATE, XFCE et Cinnamon fonctionnent, aux côtés de window managers aussi variés qu’i3, FVWM3, Window Maker, Openbox, Awesome ou Enlightenment.

Et oui, une grosse partie a été construite avec Claude Code

Le détail qui rend YServer encore plus atypique est sa méthode de développement. Le projet a été réalisé avec une aide importante de Claude Code, l’agent de programmation d’Anthropic. Le dépôt contient d’ailleurs explicitement des fichiers CLAUDE.md et AGENTS.md, et la presse Linux suit depuis plusieurs mois ce qu’elle décrit sans beaucoup de détour comme un serveur X11 « vibe coded ». It’s FOSS avait déjà documenté cette origine dès cet été , tandis que Phoronix continue de rappeler dans sa couverture de la version 1.7 l’importance de l’agent IA dans le développement du projet.

Évidemment, « développé avec une IA » ne signifie pas qu’un développeur a tapé « fais-moi X11 stp » avant de partir boire un café pendant que Claude recréait trente ans de pilotes graphiques. Jos Dehaes reste le responsable du projet et YServer dispose de tests, de CI, de contributions humaines extérieures et d’un énorme travail de comparaison avec le comportement de X.Org. Mais le simple fait qu’un développeur puisse aujourd’hui entreprendre un projet système de cette ampleur avec un agent de code comme multiplicateur de productivité mérite déjà qu’on s’y attarde. Le serveur d’affichage est précisément le genre de logiciel où une erreur de quelques octets dans un protocole vieux de plusieurs décennies peut donner un résultat légèrement moins sympathique qu’un bouton CSS mal centré.

YServer 1.7 réduit enfin son appétit pour la VRAM

La version 1.7 s’attaque justement à l’un des gros défauts observés jusqu’ici : la consommation de mémoire vidéo. Sur un bureau 4K, YServer pouvait utiliser entre 2 et 4 Go de VRAM là où X.Org se situait autour de 900 Mo dans une configuration comparable. Avec cette nouvelle version, les mesures rapportées par Phoronix descendent YServer aux alentours de 1,2 Go, grâce notamment à une meilleure gestion des fenêtres invisibles et à la correction de plusieurs fuites liées à GLX. Les pixmaps libérés passent également par un cache LRU limité à 64 Mio, avec purge des éléments inactifs, plutôt que de laisser tranquillement la mémoire graphique disparaître jusqu’à ce que votre GPU commence à écrire son testament.

Le changement est particulièrement important parce que YServer ambitionne désormais de faire fonctionner de vrais bureaux pendant de longues sessions, pas simplement quelques programmes de démonstration. Chrome et Steam disposent déjà de l’accélération GPU depuis les versions précédentes grâce au support des GLX pbuffers correctement adossés au GPU, les vidéos et jeux plein écran fonctionnent sous Cinnamon et plusieurs problèmes de réactivité ont été corrigés sur les cartes Nvidia. La liste actuelle des applications et environnements testés commence donc à ressembler davantage à celle d’un vrai serveur d’affichage qu’à une proof of concept sortie d’un week-end particulièrement caféiné.

Vulkan 1.2 pour aller chercher des GPU qui ont déjà connu Windows 8

Autre nouveauté intéressante de YServer 1.7 : le backend graphique accepte désormais Vulkan 1.2 plutôt que d’exiger un matériel plus moderne. Cela ouvre la porte à certains vieux GPU Intel, dont les générations Haswell et Ivy Bridge lorsqu’elles disposent du support Vulkan adéquat dans la pile Mesa. Les shaders sont générés pour SPIR-V compatible Vulkan 1.2, et le serveur affiche désormais une erreur compréhensible lorsqu’une capacité nécessaire manque au lieu de s’effondrer mystérieusement au démarrage.

Ce choix colle assez bien à la philosophie du projet. YServer veut être moderne dans son code sans considérer qu’un PC ayant dépassé dix ans doit automatiquement finir en dessous de la machine à café. Le projet a déjà été testé sur du matériel AMD, Intel, Nvidia, Qualcomm Snapdragon et même sur des Mac Apple Silicon utilisant Asahi Linux. Le backend repose sur des pilotes Vulkan fonctionnels et le support peut varier suivant le constructeur ; certaines fonctions GLX restent notamment problématiques avec le pilote Nvidia propriétaire. La matrice matérielle publiée par le développeur permet justement de distinguer ce qui a réellement été essayé de ce qui relève encore de la théorie.

Et maintenant, il fait tourner… CDE

Le contraste devient franchement délicieux avec l’autre vedette de cette version : Common Desktop Environment fonctionne désormais sur YServer. CDE est ce fameux environnement Unix né dans les années 1990 et popularisé sur des stations Sun, HP, IBM ou DEC, avec suffisamment de gris et de boutons en relief pour provoquer instantanément une envie de commander un écran CRT beige sur eBay. YServer 1.7 améliore largement son sous-système de polices, ajoute les fichiers .pcf.gz, corrige le traitement des propriétés PCF et met en cache les recherches afin que CDE et les applications Motif démarrent désormais à une vitesse comparable à X.Org.

C’est probablement la meilleure image possible de ce projet : un serveur d’affichage écrit en Rust en 2026 avec l’aide d’une IA fait fonctionner un desktop Unix des années 1990 grâce à Vulkan. Si quelqu’un cherchait encore une définition correcte du mot « geek », on peut arrêter les recherches ici.

Le projet essaie quand même de vérifier que l’IA n’a pas inventé X11 à sa manière

Construire un serveur X11 pose évidemment un problème assez désagréable : beaucoup d’applications reposent sur des détails de protocole et des comportements accumulés pendant des décennies. Une implémentation peut sembler correcte à l’écran tout en renvoyant une structure légèrement différente qui fera exploser un logiciel parfaitement banal trois heures plus tard. Pour éviter de transformer chaque utilisateur en bêta-testeur involontaire, YServer utilise la X.Org X Test Suite, ou XTS5 , afin de mesurer sa conformité au protocole. La suite complète prend environ cinquante minutes et pilote même automatiquement souris et clavier pendant certains scénarios.

Le projet compare également son comportement à celui d’une instance X.Org réelle pour plusieurs cas, une stratégie particulièrement intéressante lorsque l’on réimplémente un protocole ancien. Le but n’est donc pas seulement de faire apparaître une fenêtre à l’écran : il faut qu’une application croyant discuter avec X.Org reçoive les réponses qu’elle attend. Une version précédente annonçait déjà 672 tests XTS5 réussis et le projet continue d’étendre cette couverture au fur et à mesure que les extensions avancent.

Alors pourquoi refaire X11 si tout le monde passe à Wayland ?

Parce que X11 ne va pas disparaître demain matin. Même lorsque le bureau tourne nativement sous Wayland, une quantité importante de logiciels continue de dépendre de X11 à travers XWayland. Et certains utilisateurs, logiciels, environnements spécialisés ou systèmes plus anciens restent attachés à une véritable session X11. Le projet n’essaie pas forcément de mener une croisade pour renverser Wayland ; il explore plutôt la question suivante : à quoi ressemblerait un serveur X11 si on le concevait aujourd’hui sans traîner toutes les couches historiques de X.Org ?

C’est aussi un projet techniquement intéressant pour Rust. Réécrire un composant système de cette taille permet de tester jusqu’où le langage peut remplacer des couches traditionnellement écrites en C, avec sa sécurité mémoire et son système de types, sans nécessairement garder l’architecture historique correspondante. Cela ne veut pas dire que Rust supprime les bugs — le GPU trouvera toujours une manière particulièrement créative de rappeler qui commande — mais certaines familles de corruptions mémoire deviennent plus difficiles à produire.

FreeBSD, Steam, Compiz… le petit projet commence sérieusement à grossir

Depuis sa première apparition publique il y a seulement quelques mois, YServer a avancé à une vitesse assez inhabituelle. FreeBSD fonctionne désormais, Xinerama est pris en charge, le hotplug des écrans existe, le changement de disposition clavier peut être effectué à chaud, Redshift sait utiliser la correction gamma, xauth fonctionne et Compiz est également supporté grâce à l’extension GLX texture_from_pixmap. La version 1.6 avait même ajouté XDMCP pour les bureaux distants multi-utilisateurs.

L’installation reste néanmoins destinée aux curieux plutôt qu’à votre tante qui veut simplement ouvrir LibreOffice. Des paquets existent pour Arch via l’AUR ainsi que sous forme de fichiers pour Fedora, Debian, Ubuntu et Alpine, mais YServer doit accéder directement à DRM/KMS et aux périphériques d’entrée. Les instructions officielles d’installation demandent donc encore de comprendre un minimum ce qui se passe sous le capot. Le projet ne prétend d’ailleurs pas être prêt à remplacer X.Org partout ni à offrir une compatibilité parfaite avec quarante ans de logiciels.

Peut-être que le plus intéressant n’est même pas YServer

Ce qui rend ce projet fascinant dépasse finalement la question « X11 ou Wayland ? ». YServer constitue un bon exemple de ce que les agents de code commencent à rendre possible : un développeur peut s’attaquer à des composants système dont la taille aurait autrefois exigé une quantité de travail considérable, tout en utilisant l’IA pour explorer des spécifications, produire des implémentations répétitives et accélérer les cycles de correction.

Cela ne garantit absolument pas la qualité. Au contraire, plus l’agent écrit rapidement, plus les tests deviennent importants. Un serveur d’affichage possède énormément d’états, de contraintes et de comportements historiques que le modèle peut parfaitement interpréter avec une confiance impressionnante et une précision beaucoup moins impressionnante. YServer paraît justement intéressant parce que son auteur ne s’est pas arrêté au « ça marche chez moi » : XTS, comparaison avec X.Org, validation Vulkan et tests sur plusieurs matériels accompagnent le développement.

YServer 1.7 n’est donc probablement pas « le nouveau X.Org ». Wayland ne va pas faire ses cartons parce qu’un serveur X11 en Rust vient d’obtenir le support des polices CDE. Mais le projet démontre déjà quelque chose d’assez inattendu : on peut repartir d’une spécification vieille de plusieurs décennies, retirer une partie de son histoire, reconstruire le tout avec des technologies modernes et commencer à faire tourner dessus Steam, Chrome et des environnements complets.

Et le plus drôle reste peut-être le résultat final.

En 2026, pendant que le bureau Linux essaie de quitter X11… une IA aide quelqu’un à en fabriquer un nouveau.