x windows system

Certains protocoles traversent les décennies sans prendre une ride. X Window System, connu sous le nom de X11, en est l'exemple parfait : né en 1984 au MIT, il gère encore aujourd'hui l'écran, la souris et le clavier sur des millions de machines sous Linux, BSD et autres systèmes Unix. Le protocole en est à sa onzième révision depuis 1987, d'où l'appellation X11 qui lui colle à la peau. C'est un standard ouvert, piloté par la Fondation X.Org, que l'on retrouve partout où une interface graphique doit s'afficher sur un système de type Unix. Et contrairement à ce qu'on pourrait croire, il est tout à fait possible d'installer un serveur X sur la plupart des systèmes d'exploitation, Windows compris, via des outils tiers dédiés.

Qu'est-ce que X Window System et à quoi sert-il ?

Définition et origines du protocole

X Window System est un système de fenêtrage qui prend en charge l'affichage, la gestion de la souris et du clavier sur les systèmes Unix. Son rôle fondamental : fournir une couche d'abstraction entre le matériel et les applications graphiques, indépendamment du constructeur ou de la plateforme. C'est précisément cet but d'indépendance qui lui a valu un succès durable.

Le protocole porte le numéro 11, car il en est à sa onzième version depuis 1987. Voilà pourquoi on parle indifféremment de X, de X11 ou de X Window System : trois façons de désigner la même réalité. Sur macOS, X est optionnel, le système d'exploitation d'Apple utilisant nativement Quartz pour son rendu graphique. Sous Windows, aucun serveur X n'est fourni nativement, mais des implémentations tierces comme Cygwin/X ou Xming comblent ce vide.

Avant X, d'autres systèmes d'affichage graphique par point avaient émergé. Alto chez Xerox dès 1973, puis Star en 1981, Display Manager d'Apollo Computer en 1981, le Lisa d'Apple en 1983 et le Macintosh en 1984. Dans l'univers Unix, l'Andrew Project en 1982 et le terminal Blit de Rob Pike la même année avaient ouvert la voie.

Principaux systèmes d'affichage graphique avant X
Système	Année	Origine
Alto	1973	Xerox
Star	1981	Xerox
Display Manager	1981	Apollo Computer
Lisa	1983	Apple
Macintosh	1984	Apple
Terminal Blit	1982	Rob Pike
Andrew Project	1982	Université Carnegie-Mellon

Les capacités et usages concrets de X

Concrètement, X gère le rendu graphique en bitmap, ce qui le distingue d'un affichage vectoriel. Concrètement, chaque pixel affiché à l'écran fait l'objet d'une requête d'affichage traitée par le serveur X. Ce fonctionnement permet d'afficher des fenêtres aussi bien localement que sur un ordinateur distant via le réseau.

Quand X tourne sur un ordinateur autonome, il reste transparent : l'utilisateur ne le voit pas directement, mais chaque application graphique l'utilise pour s'afficher et rafraîchir l'écran. Les clients X les plus connus, souvent utilisés pour tester un paramétrage, sont Xclock, xeyes et Xlogo. D'autres applications courantes incluent xterm, xcalc, xedit et xload. X prend en charge aussi bien l'IPv4 que l'IPv6, ce qui lui confère une grande souplesse dans les environnements réseau modernes.

L'architecture client-serveur de X Window System

Un modèle client-serveur inversé

Voilà un point qui surprend toujours les néophytes : dans X, le serveur X se trouve côté utilisateur, et le client côté application. À l'opposé du modèle web classique où le serveur est distant, ici c'est l'inverse. X se place du point de vue de l'application : il fournit des services d'entrée-sortie aux programmes, ce qui en fait un serveur au sens strict.

Le serveur X reçoit des requêtes d'affichage, renvoie la position de la souris, la liste des fontes disponibles, et envoie des notifications lors d'événements clavier ou souris. Un ou plusieurs clients X se connectent à lui via le protocole X, en utilisant la bibliothèque Xlib. Le client, lui, n'est rien d'autre que l'application logicielle qui délègue toute l'interaction homme-machine au serveur.

Avant ce modèle, les applications tournaient sur une machine centralisée gérant à la fois le traitement des données et l'affichage. Le poste d'affichage ne disposait que d'un clavier et d'un écran, parfois une souris, avec un boîtier contrôleur exécutant un serveur X : c'était le terminal X. Cette séparation des responsabilités entre calcul et affichage reste l'un des apports les plus durables de X.

Le rôle du gestionnaire de fenêtres

Parmi tous les clients X, le gestionnaire de fenêtres occupe une place à part. Son rôle : gérer l'affichage, le déplacement, le redimensionnement et les décorations des fenêtres. Il peut même s'exécuter sur une machine distincte de celle hébergeant l'application, ce qui témoigne de la modularité de l'architecture.

Les gestionnaires de fenêtres vont du plus spartiate, comme twm ou evilwm, aux environnements de bureau complets comme GNOME, KDE Plasma, Xfce ou Enlightenment. Certaines interfaces, comme Sugar ou ChromeOS, abandonnent carrément la métaphore du bureau traditionnel. L'initiative freedesktop.org travaille à l'interopérabilité entre ces distincts environnements.

Les terminaux X et les clients légers

Un terminal X est, par définition, un client léger qui n'exécute qu'un serveur X. Cette architecture a permis de bâtir des parcs de terminaux bon marché : de nombreux utilisateurs accèdent simultanément au même serveur central pour exécuter leurs applications. Le protocole XDMCP (X Display Manager Control Protocol) permet à chaque terminal de dénicher les hôtes disponibles sur le réseau.

Les limites de cette démarche sont réelles. Un terminal X matériel ne gère que le clavier, la souris et l'affichage : toutes les données résident sur le serveur distant. Aujourd'hui, les terminaux X dédiés ont largement cédé la place aux PC ou clients légers modernes, qui offrent les mêmes fonctionnalités à un coût équivalent ou inférieur.

Comparatif des types de gestionnaires de fenêtres sous X
Gestionnaire	Type	Environnement de bureau
twm	Basique	Non
evilwm	Basique	Non
Enlightenment	Complet	Oui
GNOME	Complet	Oui
KDE Plasma	Complet	Oui
Xfce	Léger	Oui

Le fonctionnement réseau et l'affichage à distance

La transparence réseau native de X

X permet nativement l'affichage déporté d'une application graphique sur un ordinateur distant, que ce soit via un réseau local ou Internet en TCP/IP. C'est l'une de ses caractéristiques les plus remarquables : lancer une application sur un serveur distant et voir sa fenêtre s'afficher sur votre écran local, comme si elle tournait en local.

La procédure la plus courante passe par la commande ssh -X : on se connecte à la machine distante via SSH, puis toute application graphique lancée établit une connexion au serveur X local. Concernant la sécurité, le trafic réseau entre le serveur X et les clients X distants n'est pas chiffré par défaut. Le tunnel SSH reste la solution standard pour protéger ces échanges. Pour ceux qui veulent aller plus loin sur la question de l'configuration matérielle adaptée à l'usage réseau, quelques points méritent attention.

Les limites liées au réseau

Soyons honnêtes : X n'est pas toujours taillé pour les usages intensifs en bande passante. Un flux vidéo de résolution 640x480 en 24 bits à 30 images par seconde représente environ 211 Mbit/s non compressé, ce qui dépasse allègrement la capacité d'un réseau 100 Mbit/s pour un seul client. Pour l'animation 3D ou l'édition photo, la latence devient vite problématique.

Les versions modernes de X intègrent des extensions comme Mesa pour permettre un affichage local optimisé, contournant le modèle réseau pour piloter directement la carte vidéo. C'est là que ça pique un peu : il faut gérer explicitement ces cas particuliers, car l'architecture de base ne le fait pas automatiquement. La surcharge provient moins du protocole lui-même que du temps de latence aller-retour entre client et serveur.

Connexion et affichage depuis Windows

Windows ne fournit aucun support natif pour X. Des implémentations libres comme Cygwin/X ou Xming, mais aussi x11vnc, permettent d'afficher sous Windows des fenêtres d'applications tournant sur un système Unix. Des produits propriétaires existent également : Exceed, MKS X/Server, Reflection X ou X-Win32.

La différence avec VNC ou le Remote Desktop Protocol est fondamentale. Ces technologies déportent l'intégralité du terminal, écran, clavier et souris compris. X, lui, permet de n'afficher qu'une seule fenêtre applicative à distance. C'est une nuance importante pour les administrateurs système qui veulent intégrer des environnements hétérogènes.

L'historique et l'évolution de X Window System

Les origines au MIT et les premières versions

Juin 1984. Le MIT publie la première version de X, fruit d'une collaboration entre Jim Gettys du projet Athena et Bob Scheifler du MIT. Scheifler cherchait un environnement d'affichage pour déboguer le système Argus. Le projet Athena, soutenu conjointement par DEC, MIT et IBM, avait besoin d'un système graphique indépendant de la plateforme, capable de fonctionner sur des machines hétérogènes de différents fournisseurs.

X se pose comme le successeur direct du W Window System, qui fonctionnait sur le système V. Le choix des lettres X et W suit juste l'ordre alphabétique. En mai 1984, Scheifler remplace le protocole synchrone de W par un protocole asynchrone : X naît officiellement. La progression est rapide : la version 6 est disponible en janvier 1985, adoptée par DEC pour sa première station de travail Ultrix. Au deuxième trimestre de 1985, la version 9 ajoute le support des couleurs, ouvrant la voie au VAXstation-II/GPX. La version 10, incompatible avec la précédente pour des raisons d'alignement de données, arrive fin 1985, suivie de X10R2 en janvier 1986 et X10R3 en février 1986.

La première démonstration commerciale de X a eu lieu au salon Autofact, avec un système de conception mécanique de Cognition Inc, présenté par Jim Fulton et Jan Hardenbergh. X10R3 fut la première version déployée à grande échelle, adoptée par DEC et Hewlett-Packard. D'autres groupes ont porté X10 sur Apollo, sur les stations Sun et même sur IBM PC/AT.

Chronologie des versions majeures de X
Version	Date	Événement clé
X6	Janvier 1985	Adoption par DEC/Ultrix
X9	T2 1985	Support des couleurs
X10R3	Février 1986	Première diffusion à grande échelle
X10R4	Décembre 1986	Dernière version X10
X11	15 septembre 1987	Sortie officielle
X11R6	16 mai 1994	Publication par X Consortium, Inc.
X11R6.7	Avril 2004	Publication par Fondation X.Org

La naissance de X11 et le Consortium X

Le Western Software Laboratory de DEC, avec Smokey Wallace et Jim Gettys, prend en charge le développement de X11 en mai 1986. Le protocole est finalisé en août de la même année. La version alpha entre en tests en février 1987, la bêta en mai, et X11 sort officiellement le 15 septembre 1987. Phil Karlton et Susan Angebrandt ont dirigé la conception et la mise en œuvre du serveur X11.

En juin 1987, neuf constructeurs réunis par le MIT expriment leur souhait de maintenir une organisation neutre. En janvier 1988, le Consortium X du MIT est constitué, avec Scheifler comme directeur. Jim Fulton rejoint l'équipe en janvier 1988, Keith Packard en mars 1988. En 1993, le X Consortium, Inc., société à but non lucratif, prend le relais et publie X11R6 le 16 mai 1994. Il se dissout fin 1996 après X11R6.3, laissant un héritage open source considérable.

De The Open Group à la Fondation X.Org

En 1997, la responsabilité de X passe à The Open Group, né de la fusion de l'Open Software Foundation et de X/Open. La publication de X11R6.4 début 1998 crée la polémique : les nouvelles conditions de licence s'écartent des pratiques libres habituelles, ciblant notamment XFree86. Le retour à la licence traditionnelle survient en septembre 1998.

Début 2004, la Fondation X.Org est créée par des membres de X.Org et freedesktop.org. The Open Group lui cède le contrôle du domaine x.org. En avril 2004, X11R6.7 est publié, basé sur XFree86 4.4RC2. La Fondation adopte un modèle de développement communautaire ouvert, inspiré de la Fondation GNOME, sans intervenir au niveau technique. Hewlett-Packard figure parmi les grands soutiens institutionnels de cette organisation.

Les implémentations et environnements de X Window System

X.Org Server et XFree86

X.Org Server est aujourd'hui l'implémentation canonique de X. Depuis 2004, ce fork de XFree86 est devenu prédominant sur les distributions Linux. Avant lui, XFree86 avait régné en maître : parti comme élémentaire port de X pour les PC compatibles IBM 386, il était devenu, à la fin des années 1990, la principale source d'innovation technique dans l'écosystème X.

Les vendeurs Unix commerciaux ont habituellement pris l'implémentation de référence pour l'adapter à leur matériel. La licence libre de X a facilité cette diversification. On compte aujourd'hui de nombreuses variantes, libres et propriétaires, issues de cette base commune. La rétrocompatibilité reste un critère fondamental dans l'évolution de chaque implémentation.

X.Org Server : implémentation libre, fork de XFree86, standard depuis 2004
XFree86 : standard de fait jusqu'en 2004, port originel pour PC 386
DECwindows : implémentation DEC pour OpenVMS, avec Common Desktop Environment
XQuartz : implémentation Apple pour macOS, successeur de X11.app
Cygwin/X et Xming : implémentations libres pour Windows

X sur les autres systèmes d'exploitation

Le système d'exploitation OpenVMS de VMS Software Inc. intègre X avec le Common Desktop Environment sous la forme de DECwindows. Apple a porté X sur macOS via X11.app, désormais déprécié au profit de XQuartz. Sur les anciens systèmes Apple, System 7 et Mac OS 8/9, des serveurs tiers comme MacX d'Apple et eXodus de White Pine Software assuraient ce rôle.

Du côté des implémentations Java, WeirdX fonctionne sur toute plateforme supportant Swing 1.1 et peut même s'exécuter comme applet dans un navigateur. X Server Android est une implémentation Java open source tournant sur appareils Android. Quand un OS avec son propre système de fenêtrage accueille X, ce dernier peut fonctionner en mode rootless : le bureau X reste caché, et l'environnement hôte gère la géométrie des fenêtres X visibles à l'écran.

La programmation pour X à différents niveaux

Programmer pour X peut se faire à plusieurs niveaux d'abstraction. Le plus bas est le protocole X lui-même. Au-dessus, la bibliothèque Xlib propose une traduction directe des requêtes du protocole en appels de fonctions C : création de fenêtres, dessin dans un contexte graphique, réception d'événements. C'est la couche que la plupart des développeurs évitent aujourd'hui, au profit de boîtes à outils plus expressives.

Le niveau suivant est celui du X Toolkit (Xt), système orienté objets en C permettant de manipuler des widgets. Plusieurs jeux de widgets existent pour Xt : le jeu Athena, développé au MIT, léger et gratuit mais limité ; le jeu Motif de l'OSF, très répandu pour les applications commerciales jusqu'à l'an 2000 ; et OpenLook. L'avantage de cette architecture : on peut créer tous les widgets d'abord, puis les afficher en une seule fois, évitant ainsi les clignotements à l'écran.

Niveaux de programmation pour X Window System
Niveau	Outil	Usage principal
Bas	Protocole X	Requêtes brutes au serveur
Intermédiaire	Xlib	Création de fenêtres, événements
Haut	X Toolkit (Xt)	Widgets, interfaces graphiques
Widgets Athena	MIT	Léger, standard, gratuit
Widgets Motif	OSF	Applications commerciales

Les limites et critiques de X Window System

Les problèmes de performance et de complexité

La séparation client-serveur génère une surcharge. La plupart provient de la latence aller-retour entre client et serveur, plutôt que du protocole lui-même. Une critique récurrente : les fonctionnalités réseau de X entraînent une complexité excessive et une baisse de performance en usage purement local. On est d'accord ? C'est un reproche légitime, même si ce n'est pas la seule lecture possible.

Des solutions existent. Les implémentations modernes utilisent les sockets de domaine Unix pour les connexions sur le même hôte. L'extension MIT-SHM permet une communication via mémoire partagée, plus rapide. Mais le programmeur doit activer et gérer explicitement ces mécanismes, tout en maintenant des chemins de secours pour assurer la compatibilité avec les serveurs X distants ou les implémentations plus anciennes. Bon clairement, ce n'est pas ce qu'on appelle une architecture transparente.

Latence aller-retour entre client et serveur X
Complexité accrue pour un usage purement local
Gestion explicite des extensions de mémoire partagée requise
Nécessité de maintenir des chemins de secours pour la compatibilité

Les problèmes de sécurité

X ne dispose d'aucun mécanisme de sandboxing natif. Toute application autorisée à accéder à un poste X peut lire le contenu du clavier, observer les mouvements de la souris, capturer l'affichage et accéder au presse-papiers. Cette absence de cloisonnement constitue une faille structurelle sérieuse dans les environnements multi-utilisateurs.

Les systèmes mal configurés qui exécutent X11 comme root exposent à des risques d'escalade de privilèges. Ce vecteur a été exploité par le passé par des applications non privilégiées. Pour ce qui est de l'authentification, le tunnel SSH reste la solution usuelle pour chiffrer le trafic réseau entre serveur et clients X distants, même si cette protection n'est pas native au protocole lui-même.

Les problèmes d'interface et d'accessibilité

X ne définit aucune spécification pour la conception d'interface utilisateur : styles de boutons, menus, barres de titre, tout cela est laissé à l'appréciation de chaque application. Résultat : une grande disparité visuelle et comportementale entre les programmes, source de frustration pour utilisateurs et développeurs. La publication en 1994 de Unix-Haters Handbook y a consacré un chapitre entier. Dès 1990, Gajewska, Manasse et McCormack détaillaient ces problèmes dans Why X Is Not Our Ideal Window System.

L'Inter-Client Communication Conventions Manual (ICCCM) a la réputation d'être difficile à implémenter correctement. Sur le plan de l'accessibilité, aucun standard n'existe nativement pour X11. Le projet Orca ajoute des fonctionnalités d'accessibilité à X, couplé à ATK de GNOME et GTK. KDE propose ses propres outils, incluant convertisseur texte-parole et loupe d'écran. Les environnements LXDE, Xfce et Enlightenment cherchent la compatibilité avec ATK.

Aucune spécification d'interface utilisateur dans le protocole X
ICCCM réputé difficile à implémenter correctement
Pas de standard d'accessibilité natif pour X11
Solutions complémentaires : Orca, ATK/GNOME, outils KDE

Wayland et les alternatives à X Window System

Pourquoi chercher à remplacer X ?

L'architecture de X a beau être robuste, elle porte les cicatrices de décennies d'évolutions successives. Sécurité insuffisante, complexité de configuration, performances limitées en usage local, absence de support natif pour les procédures stockées côté serveur : autant de raisons qui ont poussé des développeurs à chercher autre chose. Historiquement, NeWS de Sun et Display PostScript de NeXT avaient tenté de remplacer X avec des systèmes basés sur PostScript, sans rencontrer le succès escompté.

La question n'est pas nouvelle. Quand Apple a racheté NeXT et utilisé NeXTSTEP pour construire Mac OS X, il a remplacé Display PostScript par Quartz. Mike Paquette, l'un des auteurs de Quartz, a expliqué que si Apple avait ajouté toutes les fonctionnalités souhaitées à X11, le résultat n'aurait plus ressemblé à X11 ni été compatible avec d'autres serveurs. C'est un aveu éloquent sur les limites structurelles du protocole.

Wayland, le successeur principal de X

Wayland est développé par plusieurs contributeurs de X.Org comme remplacement direct de X. Il fonctionne directement avec le matériel GPU via l'infrastructure DRI, sans passer par la couche réseau de X. Cette approche améliore la performance et simplifie l'architecture globale. La version 1.0 de Wayland est sortie en 2012, marquant une étape décisive dans l'adoption progressive par les distributions Linux.

Les compositeurs Wayland peuvent utiliser XWayland, un serveur X capable de fonctionner en mode rootless, pour assurer la compatibilité rétroactive avec les applications X existantes. Basé sur EGL, comme Android, Wayland représente aujourd'hui le choix par défaut sur la majorité des distributions Linux récentes. C'est là une rupture technologique majeure, même si la transition prend du temps pour les applications héritées.

Comparatif X Window System et Wayland
Critère	X Window System	Wayland
Architecture	Client-serveur réseau	Compositeur direct
Sécurité	Pas de sandbox natif	Meilleur cloisonnement
Performance locale	Latence réseau	Accès GPU direct
Compatibilité	Très large (historique)	Via XWayland
Version stable	X11 depuis 1987	1.0 depuis 2012

Les autres alternatives et solutions de remplacement

Mir, l'ancien projet de Canonical Ltd., visait initialement les appareils mobiles ARM et les postes x86. La compatibilité avec les applications clients X passait par Xmir, tandis que le compositeur UnityNext s'appuyait sur EGL, comme Android. Depuis, Mir a évolué pour devenir un compositeur Wayland plutôt qu'un serveur d'affichage alternatif indépendant.

DirectFB représente une autre approche : travailler directement avec le matériel, via une interface au niveau du noyau au framebuffer. Pour la transparence réseau, des solutions comme VNC, NX, Xpra, le Remote Desktop Protocol, Citrix XenApp et Tarantella permettent de recréer une forme de déport d'affichage sans X. Chacune a ses contraintes : VNC et RDP déportent l'intégralité du bureau, là où X permettait de ne projeter qu'une seule fenêtre applicative sur un écran distant.

Bon clairement, X Window System n'est pas près de disparaître du jour au lendemain. Des décennies de développement, des milliers d'applications, une compatibilité éprouvée : autant d'atouts que Wayland et ses concurrents mettront encore du temps à égaler pleinement. Pour qui veut comprendre les fondements de l'affichage graphique sous Unix et Linux, étudier X reste un passage obligé, presque une porte d'entrée vers toute l'histoire du logiciel libre.