YSERVER 1.4.0 est sorti le 29 juillet 2026, et le changement principal est que Chrome et Steam bénéficient désormais de l'accélération GPU sur un serveur X11 écrit en Rust depuis zéro. Les jeux en plein écran et la lecture vidéo fonctionnent sous Cinnamon, KDE Plasma gagne le redimensionnement RandR et les popups ARGB, et le projet annonce 672 tests réussis dans la suite de régression XTS5 complète, sur AMD, Intel, NVIDIA et Apple Silicon. L'autre raison de s'y intéresser est la méthode. C'est un serveur X11 écrit en grande partie avec un agent de code, dans un été où GCC et Debian débattent tous deux de l'acceptation de ce type de contribution.
The short answer
YSERVER est un serveur d'affichage X11 écrit depuis zéro en Rust par Jos Dehaes, développé en grande partie avec l'agent Claude Code. La version 1.4.0 est sortie le 29 juillet 2026. Les pixel buffers GLX reposent désormais sur un véritable pixmap GPU, ce qui ouvre les chemins accélérés à Chrome et Steam. Les complétions Present sont cadencées sur le vblank et la timeline d'acquisition de Present 1.4 est respectée. Les jeux en plein écran et la vidéo fonctionnent sous Cinnamon, et KDE Plasma gagne le redimensionnement RandR et les popups ARGB. Le projet annonce 672 tests réussis dans la suite XTS5 complète sur AMD, Intel, NVIDIA et Apple Silicon.
Écrire un serveur X depuis zéro fait partie de ces projets dont on parle et qu'on ne fait pas. Le protocole représente trente ans d'extensions accumulées, l'implémentation de référence est énorme, et la récompense en cas de réussite est la compatibilité avec des logiciels que tout le monde dit vouloir abandonner. YSERVER le fait quand même, en Rust, et la version 1.4 est celle où le projet cesse d'être une curiosité pour devenir une cible de test crédible.
Ce que change la 1.4
Le changement qui débloque le reste est peu spectaculaire : les pixel buffers GLX reposent désormais sur un véritable pixmap GPU. Ce n'était pas le cas avant, et c'est exactement le genre de manque qui pousse une application à conclure qu'elle ne peut pas utiliser l'accélération matérielle. Avec de vrais pbuffers, Chrome et Steam empruntent le chemin WebGL accéléré.
Deux correctifs de présentation l'accompagnent. Les complétions Present sont cadencées sur le vblank, et la timeline d'acquisition de Present 1.4 est respectée. Cette combinaison corrige les clients en roue libre, la lecture vidéo en plein écran et l'indicateur de chargement de Plasma, trois symptômes de la même famille de bug : un client qui n'apprend jamais quand son image a réellement été affichée.
Les tampons de balayage sont désormais alloués via GBM puis importés dans Vulkan, ce qui élargit l'éventail de pilotes et de modificateurs de format DRM fonctionnels. C'est la même plomberie de modificateurs qui revient ailleurs dans la pile graphique ce mois ci.
La moitié moins visible de la version
Les notes de version sont longues, et la plupart des entrées relèvent de la compatibilité plutôt que de la capacité. Quelques unes méritent d'être citées, parce qu'elles montrent ce qu'il faut pour être un vrai serveur X et non une démonstration.
RANDR lit et écrit désormais les propriétés de sortie, transmet l'identité de la sortie dont l'EDID, EDID_DATA et ConnectorType, rapporte des fréquences de rafraîchissement fractionnaires issues des vrais timings du noyau, et utilise des noms de sorties compatibles Xorg, donc HDMI-1 et non HDMI-A-1. Chaque script et chaque outil de configuration qui analyse la sortie de xrandr dépend de ce dernier détail.
Le changement de disposition clavier efface maintenant les surcharges obsolètes par touche et diffuse un MappingNotify historique, pour que les clients prennent effectivement la nouvelle disposition. FreeColors est traité au lieu d'échouer en BadRequest, ce dont les applications Tk ont besoin. La comptabilité X-Resource rapporte LocalClientPID dans QueryClientIds. Les réglages libinput par périphérique pour souris et pavés tactiles s'appliquent correctement, l'historique de déplacement du pointeur fonctionne via GetMotionEvents, et XI2 gagne les deltas RawMotion relatifs, l'arrêt du défilement au lever du doigt, les captures implicites de pointeur et un état de gel unifié.
Côté RENDER, toute la famille PictOp standard est implémentée, les destinations à masque a8 fonctionnent pour CompositeGlyphs, et le rendu de glyphes est regroupé en un seul appel de dessin instancié par bloc de texte.
Il y a aussi un lanceur starty dans la tradition de startx, qui gère le choix du numéro d'affichage, l'authentification MIT-MAGIC-COOKIE-1 et la fermeture de session, plus des pages de manuel et des améliorations d'empaquetage. La dépendance à libseat est abandonnée au profit d'un modèle de siège direct uniquement. Et le serveur est réellement au repos quand rien ne se passe, avec équité et contre pression dans la boucle principale, ce qui compte plus qu'il n'y paraît quand on a déjà vu un serveur X consommer un cœur pour rien.
Ce que le chiffre de conformité dit, et ne dit pas
672 tests XTS5 réussis sur AMD, Intel, NVIDIA et Apple Silicon est un vrai signal, et c'est la bonne façon de mesurer ce type de projet. XTS5 est la X Test Suite, et la faire tourner sur quatre fabricants de GPU représente plus de rigueur que ce que s'imposent la plupart des projets amateurs.
Ce n'est pas une affirmation de complétude. XTS5 est antérieure à une grande partie de ce que font les applications modernes, donc la réussir signifie que le comportement du protocole est correct, pas que GTK 4 sera satisfait pendant une semaine. Une suite de tests ne dit rien non plus des modes de défaillance qui comptent à l'usage : croissance mémoire sur les longues sessions, comportement lors d'un reset GPU, réaction à un branchement d'écran au mauvais moment.
Notre lecture est que YSERVER est désormais une bonne cible de test et pas encore un outil quotidien. Si vous maintenez un client X, une boîte à outils ou un gestionnaire de fenêtres, l'exécuter face à une implémentation indépendante du protocole révélera dans votre code des bugs que le serveur de référence tolère discrètement depuis des années. C'est réellement utile, et cela n'exige pas de miser votre session dessus.
La question de la provenance, encore
YSERVER a été écrit en grande partie avec Claude Code, et le dépôt contient un CLAUDE.md et un AGENTS.md. L'auteur l'assume, ce qui est la seule façon raisonnable de procéder.
Cela tombe au milieu d'un débat. GCC a décidé de refuser les contributions substantielles générées par IA, avec une exception pour les cas de test. Debian mène une résolution générale sur les contributions écrites par des LLM. Et Starling, un bureau Linux écrit en Swift avec Claude, est apparu deux jours avant cette version.
Les deux camps de ce débat ne sont pas vraiment en contradiction, parce qu'ils répondent à des questions différentes. GCC et Debian raisonnent sur la provenance, le droit d'auteur et la charge de relecture, à l'intérieur de bases de code dont dépendent des milliers de projets et qui doivent rester maintenables pendant des décennies. Un projet neuf sous licence MIT avec un auteur principal ne porte aucun de ces risques, et pose une question plus étroite : cette méthode peut elle produire un serveur X qui fonctionne ?
La 1.4 est une réponse raisonnable à cette question étroite. Trois développeurs extérieurs y ont fait leurs premières contributions, et l'un d'eux a corrigé la compilation avec la chaîne stable sur Ubuntu 26.04, le genre de correctif ingrat qui n'arrive que lorsque des gens utilisent réellement un logiciel.
Sources et pour aller plus loin
- Notes de version de YSERVER 1.4.0 sur GitHub
- Le dépôt joske/yserver
- Phoronix : YSERVER fait tourner Steam et des jeux plein écran sous Cinnamon
- Linux Compatible : YServer 1.4.0, le serveur X11 natif Rust atteint un cap utilisable
- It's FOSS : un nouveau serveur X11 écrit en Rust avec l'aide de l'IA
Questions fréquentes
Qu'est ce que YSERVER, et qui l'écrit ?
YSERVER est un serveur d'affichage X11 écrit depuis zéro en Rust, sous licence MIT, développé par Jos Dehaes dans le dépôt joske/yserver sur GitHub. Il est apparu publiquement au début de l'été 2026 et enchaîne les versions depuis. Ce n'est pas un fork de Xorg, ni une variante de XWayland. Il implémente directement le protocole X11, et c'est pourquoi le projet se mesure à la suite de conformité XTS5 plutôt qu'à une liste de fonctionnalités. La version 1.4.0 a été publiée le 29 juillet 2026 et intègre les premières contributions de trois développeurs extérieurs à l'auteur d'origine.
En quoi consiste concrètement l'accélération GPU pour Chrome et Steam ?
Le changement précis porte sur les pixel buffers GLX. YSERVER 1.4 fait reposer les pbuffers sur un véritable pixmap GPU plutôt que sur une émulation côté serveur, et c'est ce qui permet à Chrome et Steam d'emprunter le chemin WebGL accéléré au lieu de retomber en logiciel. À côté, les complétions Present sont désormais cadencées sur le vblank et la timeline d'acquisition de Present 1.4 est respectée, ce qui corrige les clients en roue libre, la vidéo plein écran et l'indicateur de chargement de Plasma. Les tampons de balayage sont aussi alloués via GBM puis importés dans Vulkan, ce qui élargit la couverture des pilotes et des modificateurs de format DRM. Ensemble, ce sont ces changements qui transforment une implémentation de protocole en quelque chose sur quoi regarder une vidéo.
Quels bureaux et quels matériels sont pris en charge ?
Le projet annonce un fonctionnement avec MATE, Xfce, Cinnamon, KDE Plasma et les gestionnaires de fenêtres classiques, et Sonic DE, un fork X11 de Plasma, a été testé avec succès. La version 1.4 ajoute le redimensionnement RandR sous Plasma et la transparence des popups ARGB, ainsi que les jeux en plein écran et la lecture vidéo sous Cinnamon. YSERVER a récemment été qualifié sur openSUSE Tumbleweed avec KDE Plasma sur matériel NVIDIA. La suite de régression XTS5 tourne sur AMD, Intel, NVIDIA et Apple Silicon avec 672 tests réussis. La version 1.3 avait déjà ajouté le support de FreeBSD et Xinerama, la cible ne se limite donc pas à Linux.
Peut il remplacer Xorg sur une machine qui compte ?
Non, et le projet ne le prétend pas. Réussir 672 tests XTS5 est un signal de conformité significatif, ce n'est pas la même chose que la complétude, car XTS5 ne couvre pas tout ce que font les applications réelles et un passage de suite ne dit rien de la stabilité sur des semaines de fonctionnement. L'usage raisonnable aujourd'hui, c'est le test : garder les applications X11 honnêtes, vérifier le comportement d'une boîte à outils face à une implémentation indépendante du protocole, ou éprouver votre propre client X contre autre chose que le serveur de référence. Qui dépend de sa session de bureau devrait rester sur Xorg ou Wayland et surveiller ce projet en parallèle.
Pourquoi la question de l'écriture par IA compte t elle ?
Parce que c'est un point de données dans un débat que le logiciel libre mène en ce moment. YSERVER a été écrit en grande partie avec Claude Code, et le dépôt contient à la fois un CLAUDE.md et un AGENTS.md. Dans les mêmes semaines, GCC a décidé de refuser les contributions substantielles générées par IA, avec une exception pour les cas de test, et Debian a mis aux voix le traitement des contributions écrites par des LLM. Ces projets raisonnent sur la provenance, le droit d'auteur et la charge de relecture, sur des bases de code qui existent déjà et doivent continuer de fonctionner pendant des décennies. YSERVER est l'autre expérience : un projet neuf où la seule question est de savoir si la méthode peut produire un serveur X qui fonctionne. Au vu de la 1.4, elle produit quelque chose qui fait tourner Steam.