Système X Window

Le système X Window ( X11 , ou simplement X ; stylisé 𝕏 ) est un système de fenêtrage pour les affichages bitmap , courant sur les systèmes d'exploitation de type Unix .

X est né dans le cadre du projet Athena au Massachusetts Institute of Technology (MIT) en 1984. Le protocole X est à la version 11 (d'où « X11 ») depuis septembre 1987. La Fondation X.Org dirige le projet X, avec l'implémentation de référence actuelle, X.Org Server , disponible en tant que logiciel libre et open source sous la licence MIT et des licences permissives similaires.

X est un système indépendant de l'architecture pour les interfaces utilisateur graphiques distantes et les capacités des périphériques d'entrée. Chaque personne utilisant un terminal en réseau a la possibilité d'interagir avec l'écran avec n'importe quel type de périphérique d'entrée utilisateur.

Dans sa distribution standard, il s'agit d'une solution d'affichage et d'interface complète, bien que simple, qui fournit une boîte à outils et une pile de protocoles standard pour la création d'interfaces utilisateur graphiques sur la plupart des systèmes d'exploitation de type Unix et OpenVMS , et a été portée sur de nombreux autres systèmes d'exploitation contemporains à usage général .

X fournit le cadre de base , ou les primitives, pour la construction de tels environnements d'interface utilisateur graphique : dessiner et déplacer des fenêtres sur l' écran et interagir avec une souris, un clavier ou un écran tactile. X n'impose pas l' interface utilisateur ; les programmes clients individuels s'en chargent. Les programmes peuvent utiliser les capacités graphiques de X sans interface utilisateur. Ainsi, le style visuel des environnements basés sur X varie considérablement ; différents programmes peuvent présenter des interfaces radicalement différentes.

Contrairement à la plupart des protocoles d'affichage antérieurs, X a été spécifiquement conçu pour être utilisé sur des connexions réseau plutôt que sur un périphérique d'affichage intégré ou connecté. X présente une transparence réseau , ce qui signifie qu'un programme X exécuté sur un ordinateur situé quelque part sur un réseau (tel qu'Internet) peut afficher son interface utilisateur sur un serveur X exécuté sur un autre ordinateur du réseau. Le serveur X est généralement le fournisseur de ressources graphiques et d'événements clavier/souris aux clients X , ce qui signifie que le serveur X s'exécute généralement sur l'ordinateur devant un utilisateur humain, tandis que les applications clientes X s'exécutent n'importe où sur le réseau et communiquent avec l'ordinateur de l'utilisateur pour demander le rendu du contenu graphique et recevoir des événements des périphériques d'entrée, notamment les claviers et les souris.

Le fait que le terme « serveur » soit appliqué au logiciel devant l'utilisateur est souvent surprenant pour les utilisateurs habitués à ce que leurs programmes soient des clients de services sur des ordinateurs distants. Ici, plutôt qu'une base de données distante qui constitue la ressource d'une application locale, les périphériques d'affichage et d'entrée graphiques de l'utilisateur deviennent des ressources mises à disposition par le serveur X local pour les programmes clients X locaux et hébergés à distance qui doivent partager les périphériques graphiques et d'entrée de l'utilisateur pour communiquer avec ce dernier.

Le protocole réseau de X est basé sur les primitives de commande X. Cette approche permet aux opérations 2D et 3D (via des extensions comme GLX) d'une application cliente X qui peut être exécutée sur un autre ordinateur d'être entièrement accélérées sur l'affichage du serveur X. Par exemple, dans OpenGL classique (avant la version 3.0), des listes d'affichage contenant un grand nombre d'objets pouvaient être construites et stockées entièrement sur le serveur X par un programme client X distant, puis chacune rendue en envoyant une seule glCallList( which) sur le réseau.

X ne fournit aucun support natif pour l'audio ; plusieurs projets existent pour combler ce créneau, certains fournissant également un support réseau transparent .

X utilise un modèle client-serveur : un serveur X communique avec différents programmes clients . Le serveur accepte les demandes de sortie graphique (fenêtres) et renvoie les entrées utilisateur (à partir du clavier, de la souris ou de l'écran tactile). Le serveur peut fonctionner comme :

• une application s'affichant dans une fenêtre d'un autre système d'affichage
• un programme système contrôlant la sortie vidéo d'un PC
• un élément matériel dédié

Cette terminologie client-serveur (le terminal de l'utilisateur étant le serveur et les applications les clients) est souvent source de confusion pour les nouveaux utilisateurs de X, car les termes semblent inversés. Mais X adopte la perspective de l'application plutôt que celle de l'utilisateur final : X fournit des services d'affichage et d'E/S aux applications, il s'agit donc d'un serveur ; les applications utilisent ces services, elles sont donc des clients.

Le protocole de communication entre le serveur et le client fonctionne de manière transparente au niveau du réseau : le client et le serveur peuvent fonctionner sur la même machine ou sur des machines différentes, éventuellement avec des architectures et des systèmes d'exploitation différents. Un client et un serveur peuvent même communiquer de manière sécurisée sur Internet en tunnelant la connexion via une session réseau cryptée.

Un client X lui-même peut émuler un serveur X en fournissant des services d'affichage à d'autres clients. C'est ce qu'on appelle « l'imbrication X ». Les clients open source tels que Xnest et Xephyr prennent en charge cette imbrication X.

Pour exécuter une application client X sur une machine distante, l'utilisateur peut procéder comme suit :

• sur la machine locale, ouvrez une fenêtre de terminal
• utiliser ssh -Xla commande pour se connecter à la machine distante
• demander un service d'affichage/d'entrée local (par exemple, si vous n'utilisez pas SSH avec le transfert X activé)export DISPLAY=[user's machine]:0

L'application client X distante établira ensuite une connexion au serveur X local de l'utilisateur, fournissant un affichage et une saisie à l'utilisateur.

Alternativement, la machine locale peut exécuter un petit programme qui se connecte à la machine distante et démarre l’application cliente.

Voici quelques exemples concrets de clients distants :

• administrer une machine distante graphiquement (similaire à l'utilisation du bureau à distance, mais avec des fenêtres uniques)
• utiliser une application client pour rejoindre un grand nombre d'autres utilisateurs de terminaux dans des groupes de travail collaboratifs
• exécuter une simulation à forte intensité de calcul sur une machine distante et afficher les résultats sur une machine de bureau locale
• exécuter un logiciel graphique sur plusieurs machines à la fois, contrôlé par un seul écran, un seul clavier et une seule souris

X définit principalement les primitives de protocole et de graphisme. Il ne contient délibérément aucune spécification pour la conception de l'interface utilisateur de l'application, comme les styles de boutons, de menus ou de barres de titre de fenêtre. Au lieu de cela, les logiciels d'application, tels que les gestionnaires de fenêtres, les boîtes à outils de widgets d'interface utilisateur graphique et les environnements de bureau, ou les interfaces utilisateur graphiques spécifiques à l'application, définissent et fournissent ces détails. Par conséquent, il n'existe pas d'interface X typique et plusieurs environnements de bureau différents sont devenus populaires auprès des utilisateurs.

Un gestionnaire de fenêtres contrôle le placement et l'apparence des fenêtres d'application. Cela peut donner lieu à des interfaces de bureau rappelant celles de Microsoft Windows ou d'Apple Macintosh (par exemple GNOME 2, KDE Plasma, Xfce) ou avoir des contrôles radicalement différents (comme un gestionnaire de fenêtres en mosaïque, comme wmii ou Ratpoison ). Certaines interfaces telles que Sugar ou ChromeOS évitent complètement la métaphore du bureau, simplifiant leurs interfaces pour les applications spécialisées. Les gestionnaires de fenêtres varient en sophistication et en complexité, depuis les plus basiques ( par exemple , twm, le gestionnaire de fenêtres de base fourni avec X, ou evilwm, un gestionnaire de fenêtres extrêmement léger) jusqu'aux environnements de bureau plus complets tels qu'Enlightenment et même aux gestionnaires de fenêtres spécifiques aux applications pour les marchés verticaux tels que les points de vente.

De nombreux utilisateurs utilisent X avec un environnement de bureau qui, outre le gestionnaire de fenêtres, comprend diverses applications utilisant une interface utilisateur cohérente. Les environnements de bureau les plus populaires incluent GNOME , KDE Plasma et Xfce . L'environnement standard UNIX 98 est le Common Desktop Environment (CDE). L'initiative freedesktop.org aborde l'interopérabilité entre les bureaux et les composants nécessaires à un bureau X compétitif.

L'implémentation X.Org est l'implémentation canonique de X. En raison de la libéralisation des licences, un certain nombre de variantes, à la fois libres, open source et propriétaires, sont apparues. Les fournisseurs commerciaux d'Unix ont eu tendance à prendre l'implémentation de référence et à l'adapter à leur matériel, généralement en la personnalisant et en ajoutant des extensions propriétaires.

Jusqu'en 2004, XFree86 était la variante X la plus courante sur les systèmes libres de type Unix. XFree86 a commencé comme un portage de X sur des PC compatibles 386 et, à la fin des années 1990, était devenu la plus grande source d'innovation technique dans X et le standard de facto du développement de X. Depuis 2004, cependant, le serveur X.Org, un fork de XFree86, est devenu prédominant.

Bien qu'il soit courant d'associer X à Unix, les serveurs X existent également de manière native dans d'autres environnements graphiques. Le système d'exploitation OpenVMS de VMS Software Inc. inclut une version de X avec Common Desktop Environment (CDE), connu sous le nom de DECwindows, comme environnement de bureau standard. Apple a initialement porté X sur macOS sous la forme de X11.app, mais cette version a été abandonnée au profit de l' implémentation XQuartz . Les serveurs tiers sous les anciens systèmes d'exploitation d'Apple dans les années 1990, System 7 et Mac OS 8 et 9, comprenaient MacX d'Apple et eXodus de White Pine Software.

Microsoft Windows n'est pas livré avec la prise en charge de X, mais de nombreuses implémentations tierces existent, sous forme de logiciels libres et open source tels que Cygwin/X , et de produits propriétaires tels que Exceed, MKS X/Server, Reflection X, X-Win32 et Xming .

Il existe également des implémentations Java de serveurs X. WeirdX fonctionne sur n'importe quelle plate-forme prenant en charge Swing 1.1 et s'exécute sous forme d'applet dans la plupart des navigateurs. Android X Server est une implémentation Java open source qui fonctionne sur les appareils Android.

Lorsqu'un système d'exploitation avec un système de fenêtrage natif héberge X en plus, le système X peut soit utiliser son propre bureau normal dans une fenêtre hôte distincte, soit s'exécuter sans racine , ce qui signifie que le bureau X est masqué et que l'environnement de fenêtrage de l'hôte gère la géométrie et l'apparence des fenêtres X hébergées dans l'écran de l'hôte.

Un terminal X est un client léger qui exécute uniquement un serveur X. Cette architecture est devenue populaire pour la construction de parcs de terminaux peu coûteux permettant à de nombreux utilisateurs d'utiliser simultanément le même grand serveur informatique pour exécuter des programmes d'application en tant que clients du terminal X de chaque utilisateur. Cette utilisation est tout à fait conforme à l'intention initiale du projet MIT.

Les terminaux X explorent le réseau (le domaine de diffusion local ) à l'aide du protocole de contrôle du gestionnaire d'affichage X pour générer une liste d'hôtes disponibles autorisés en tant que clients. L'un des hôtes clients doit exécuter un gestionnaire d'affichage X.

L'une des limitations des terminaux X et de la plupart des clients légers est qu'ils ne sont pas capables d'effectuer d'autres entrées ou sorties que le clavier, la souris et l'écran. Toutes les données pertinentes sont supposées exister uniquement sur le serveur distant et l'utilisateur du terminal X ne dispose d'aucune méthode pour enregistrer ou charger des données à partir d'un périphérique local .

Les terminaux X dédiés (matériels) sont tombés en désuétude ; un PC ou un client léger moderne avec un serveur X fournit généralement les mêmes fonctionnalités au même coût, voire à un coût inférieur.

Le manuel Unix-Haters Handbook (1994) a consacré un chapitre entier aux problèmes de X. Why X Is Not Our Ideal Window System (1990) de Gajewska, Manasse et McCormack a détaillé les problèmes du protocole avec des recommandations d'amélioration.

L'absence de directives de conception dans X a donné lieu à plusieurs interfaces très différentes et à des applications qui ne fonctionnent pas toujours bien ensemble. Le manuel des conventions de communication inter-clients (ICCCM), une spécification pour l'interopérabilité des clients, a la réputation d'être difficile à mettre en œuvre correctement. D'autres efforts de normalisation tels que Motif et CDE n'ont pas atténué les problèmes. Cela a frustré les utilisateurs et les programmeurs. l'apparence et de la communication des applications en codant pour un environnement de bureau spécifique ou pour une boîte à outils de widgets spécifique, ce qui évite également d'avoir à traiter directement avec l'ICCCM.

X ne prend pas non plus en charge nativement les procédures stockées définies par l'utilisateur sur le serveur X, à la manière de NeWS : il n'y a pas de fonction de script Turing-complet . Différents environnements de bureau peuvent donc proposer leurs propres fonctions (généralement incompatibles entre elles).

Les systèmes basés sur X peuvent avoir des problèmes d'accessibilité qui rendent l'utilisation d'un ordinateur difficile pour les utilisateurs handicapés, notamment le clic droit , le double-clic , le clic du milieu , le survol de la souris et le vol de focus . Certains clients X11 gèrent mieux les problèmes d'accessibilité que d'autres, de sorte que les personnes ayant des problèmes d'accessibilité ne sont pas exclues de l'utilisation de X11. Cependant, il n'existe pas de norme d'accessibilité ni de directives d'accessibilité pour X11. Au sein du processus de normalisation X11, il n'existe pas de groupe de travail sur l'accessibilité ; cependant, les besoins en matière d'accessibilité sont pris en compte par des projets logiciels pour fournir ces fonctionnalités en plus de X.

Le projet Orca ajoute un support d'accessibilité au système X Window, notamment en implémentant une API ( AT-SPI ). Celui-ci est couplé à l'ATK de GNOME pour permettre l'implémentation de fonctionnalités d'accessibilité dans les programmes X en utilisant les API GNOME/GTK. KDE fournit un ensemble différent de logiciels d'accessibilité, notamment un convertisseur texte-parole et une loupe d'écran. Les autres principaux bureaux (LXDE, Xfce et Enlightenment) tentent d'être compatibles avec l'ATK.

Un client X ne peut généralement pas être détaché d'un serveur et rattaché à un autre à moins que son code ne le prévoie spécifiquement ( Emacs est l'un des rares programmes courants dotés de cette capacité). Ainsi, déplacer une session entière d'un serveur X à un autre n'est généralement pas possible. Cependant, des approches comme Virtual Network Computing (VNC), NX et Xpra permettent d'atteindre une session virtuelle à partir de différents serveurs X (d'une manière similaire à GNU Screen en relation avec les terminaux), et d'autres applications et boîtes à outils fournissent des fonctionnalités similaires. Des solutions de contournement comme x11vnc ( VNC :0 views ), le mode shadow de Xpra et le mode shadow nxagent de NX existent également pour rendre l'écran actuel du serveur X disponible. Cette capacité permet de basculer l'interface utilisateur (souris, clavier, moniteur) d'une application en cours d'exécution d'un emplacement à un autre sans arrêter et redémarrer l'application.

Le trafic réseau entre un serveur X et des clients X distants n'est pas chiffré par défaut. Un attaquant doté d'un analyseur de paquets peut l'intercepter, ce qui lui permet de visualiser tout ce qui est affiché ou envoyé depuis l'écran de l'utilisateur. La méthode la plus courante pour chiffrer le trafic X consiste à établir un tunnel Secure Shell (SSH) pour la communication.

Comme tous les clients légers , lors de l'utilisation de X sur un réseau, les limitations de bande passante peuvent entraver l'utilisation d' applications gourmandes en bitmap qui nécessitent une mise à jour rapide de grandes parties de l'écran avec une faible latence, telles que l'animation 3D ou l'édition de photos. Même un flux vidéo 640×480×24 bits à 30 ips non compressé relativement petit (~211 Mbit/s) peut facilement dépasser la bande passante d'un réseau à 100 Mbit/s pour un seul client. En revanche, les versions modernes de X ont généralement des extensions telles que Mesa permettant d'optimiser l'affichage local des graphiques d'un programme local pour contourner le modèle de réseau et contrôler directement la carte vidéo, pour l'utilisation de vidéos en plein écran, d'applications 3D rendues et d'autres applications de ce type.

La conception de X nécessite que les clients et le serveur fonctionnent séparément, et l'indépendance des appareils et la séparation du client et du serveur entraînent des frais généraux. La majeure partie de ces frais généraux provient du temps de réponse aller-retour entre le client et le serveur ( latence ) plutôt que du protocole lui-même : les meilleures solutions aux problèmes de performances dépendent d'une conception efficace des applications. Une critique courante de X est que ses fonctionnalités réseau entraînent une complexité excessive et une diminution des performances si elles ne sont utilisées que localement.

Les implémentations X modernes utilisent des sockets de domaine Unix pour des connexions efficaces sur le même hôte. De plus, la mémoire partagée (via l' extension MIT-SHM ) peut être utilisée pour une communication client-serveur plus rapide. Cependant, le programmeur doit toujours activer et utiliser explicitement l'extension de mémoire partagée. Il est également nécessaire de fournir des chemins de secours afin de rester compatible avec les implémentations plus anciennes et afin de communiquer avec des serveurs X non locaux.

Certaines personnes ont tenté d'écrire des alternatives et des remplacements à X. Les alternatives historiques incluent NeWS de Sun et Display PostScript de NeXT , tous deux des systèmes basés sur PostScript prenant en charge les procédures d'affichage définissables par l'utilisateur, ce qui manquait à X. Les alternatives actuelles incluent :

• macOS (et son homologue mobile, iOS ) implémente son système de fenêtrage, connu sous le nom de Quartz . Lorsque Apple Computer a acheté NeXT et a 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é la prise en charge de toutes les fonctionnalités qu'il souhaitait inclure dans X11, il n'aurait de toute façon pas beaucoup de ressemblance avec X11 ni ne serait compatible avec d'autres serveurs.
• Wayland est développé par plusieurs développeurs X.Org comme un remplacement potentiel de X. Il fonctionne directement avec le matériel GPU , via DRI . Wayland peut exécuter un serveur X en tant que compositeur Wayland, qui peut être sans racine. Le projet a atteint la version 1.0 en 2012. Comme Android, Wayland est basé sur EGL .
• Mir était un projet de Canonical Ltd. avec des objectifs similaires à Wayland. Mir était destiné à fonctionner avec des appareils mobiles utilisant des chipsets ARM (un objectif déclaré était la compatibilité avec les pilotes de périphériques Android) ainsi qu'avec des ordinateurs de bureau x86. Comme Android, Mir/UnityNext étaient basés sur EGL. La rétrocompatibilité avec les applications clientes X était réalisée via Xmir. Le projet est depuis devenu un compositeur Wayland au lieu d'être un serveur d'affichage alternatif .
• D'autres alternatives tentent d'éviter la surcharge de X en travaillant directement avec le matériel ; de tels projets incluent DirectFB . L' infrastructure de rendu direct (DRI) fournit une interface au niveau du noyau au framebuffer .

D'autres moyens permettant d'obtenir une forme fonctionnelle de la fonctionnalité de « transparence du réseau » de X, via la transmissibilité réseau des services graphiques, incluent :

• Virtual Network Computing (VNC), un système de très bas niveau qui envoie des bitmaps compressés sur le réseau ; l'implémentation Unix comprend un serveur X
• Le protocole RDP (Remote Desktop Protocol ), qui est similaire à VNC dans son objectif, mais qui est originaire de Microsoft Windows avant d'être porté sur des systèmes de type Unix, par exemple NX
• Citrix XenApp , un protocole de type X et une pile d'applications pour Microsoft Windows
• Tarantella , qui fournit un client d'interface graphique distant basé sur Java à utiliser dans les navigateurs Web

Plusieurs systèmes d'affichage bitmap ont précédé X. Xerox a présenté l' Alto (1973) et le Star (1981). Apollo Computer a présenté Display Manager (1981). Apple a présenté Lisa (1983) et Macintosh (1984). Le monde Unix a présenté le projet Andrew (1982) et le terminal Blit de Rob Pike (1982).

L'université Carnegie Mellon a produit une application d'accès à distance appelée Alto Terminal, qui affichait des fenêtres superposées sur le Xerox Alto et rendait les hôtes distants (généralement des systèmes DEC VAX exécutant Unix) responsables de la gestion des événements d'exposition des fenêtres et de l'actualisation du contenu des fenêtres si nécessaire.

X tire son nom du successeur d'un système de fenêtres antérieur à 1983 appelé W (la lettre précédant X dans l' alphabet anglais ). W fonctionnait sous le système d'exploitation V. W utilisait un protocole réseau prenant en charge les fenêtres de terminal et graphiques, le serveur gérant les listes d'affichage.

L'idée originale de X est née au MIT en 1984, suite à une collaboration entre Jim Gettys (du projet Athena ) et Bob Scheifler (du laboratoire d'informatique du MIT ). Scheifler avait besoin d'un environnement d'affichage utilisable pour déboguer le système Argus. Le projet Athena (un projet conjoint entre DEC , MIT et IBM pour fournir un accès facile aux ressources informatiques à tous les étudiants) avait besoin d'un système graphique indépendant de la plate-forme pour relier ses systèmes hétérogènes à plusieurs fournisseurs ; le système de fenêtres alors en cours de développement dans le cadre du projet Andrew de l'université Carnegie Mellon ne permettait pas de disposer de licences et aucune alternative n'existait.

Le projet a résolu ce problème en créant un protocole capable à la fois d'exécuter des applications locales et d'appeler des ressources distantes. Au milieu de l'année 1983, un premier portage de W vers Unix fonctionnait à un cinquième de sa vitesse sous V ; en mai 1984, Scheifler a remplacé le protocole synchrone de W par un protocole asynchrone et les listes d'affichage par des graphiques en mode immédiat pour faire de X la version 1. X est devenu le premier environnement de système de fenêtrage à offrir une véritable indépendance matérielle et vis-à-vis des fournisseurs.

Scheifler, Gettys et Ron Newman se mirent au travail et X progressa rapidement. Ils sortirent la version 6 en janvier 1985. DEC, qui s'apprêtait alors à sortir sa première station de travail Ultrix , jugea que X était le seul système de fenêtrage susceptible d'être disponible à temps. Les ingénieurs de DEC portèrent X6 sur l'écran QVSS de DEC sur MicroVAX .

Au deuxième trimestre 1985, X a acquis le support couleur pour fonctionner dans le DEC VAXstation -II/GPX, formant ce qui est devenu la version 9.

Un groupe de l'Université Brown a porté la version 9 sur l' IBM RT PC , mais des problèmes de lecture de données non alignées sur le RT ont forcé un changement de protocole incompatible, conduisant à la version 10 à la fin de 1985. X10R1 a été publié en 1985. En 1986, des organisations extérieures avaient commencé à demander X. X10R2 a été publié en janvier 1986, puis X10R3 en février 1986. Bien que le MIT ait accordé une licence pour X6 à certains groupes extérieurs contre rémunération, il a décidé à ce moment-là de concéder une licence pour X10R3 et les versions futures sous ce qui est devenu la licence MIT , dans l'intention de populariser davantage X et, en retour, dans l'espoir que de nombreuses autres applications seraient disponibles. X10R3 est devenu la première version à atteindre un déploiement à grande échelle, avec DEC et Hewlett-Packard publiant des produits basés sur elle. D'autres groupes ont porté X10 sur Apollo et sur les stations de travail Sun et même sur l'IBM PC/AT . Des démonstrations de la première application commerciale de X (un système d'ingénierie mécanique assistée par ordinateur de Cognition Inc. qui fonctionnait sur des VAX et s'affichait à distance sur des PC exécutant un serveur X porté par Jim Fulton et Jan Hardenbergh) ont eu lieu au salon Autofact à cette époque. La dernière version de X10, X10R4, est apparue en décembre 1986. Des tentatives ont été faites pour permettre aux serveurs X d'être des dispositifs de collaboration en temps réel, à l'image de Virtual Network Computing (VNC) qui permettrait plus tard de partager un bureau. L'un de ces premiers efforts a été l'outil SharedX de Philip J. Gust .

Bien que X10 offrait des fonctionnalités intéressantes et puissantes, il était devenu évident que le protocole X pouvait bénéficier d'une refonte plus neutre du point de vue du matériel avant d'être trop largement déployé, mais le MIT seul n'aurait pas les ressources nécessaires pour une refonte aussi complète. Il se trouve que le Western Software Laboratory de DEC s'est retrouvé entre deux projets avec une équipe expérimentée. Smokey Wallace de DEC WSL et Jim Gettys ont proposé que DEC WSL construise X11 et le rende disponible gratuitement sous les mêmes conditions que X9 et X10. Ce processus a commencé en mai 1986, le protocole étant finalisé en août. Les tests alpha du logiciel ont commencé en février 1987, les tests bêta en mai ; la sortie de X11 a finalement eu lieu le 15 septembre 1987.

La conception du protocole X11, dirigée par Scheifler, a été largement discutée sur les listes de diffusion ouvertes sur l'Internet naissant qui étaient reliées aux groupes de discussion USENET. Gettys a déménagé en Californie pour aider à diriger les travaux de développement de X11 au WSL depuis le Centre de recherche sur les systèmes du DEC, où Phil Karlton et Susan Angebrandt ont dirigé la conception et la mise en œuvre du serveur d'échantillons X11. X représente donc l'un des premiers projets de logiciels libres et open source distribués à très grande échelle .

À la fin des années 1980, X était, comme l'écrivait Simson Garfinkel en 1989, « la réalisation la plus importante d'Athena à ce jour ». DEC aurait estimé que son développement à lui seul avait justifié la donation de la société au MIT. Gettys a rejoint l'équipe de conception de la VAXstation 2000 pour s'assurer que X, que DEC appelait DECwindows , fonctionnerait dessus, et la société a affecté 1 200 employés au portage de X sur Ultrix et VMS. En 1987, le succès de X11 devenant évident, le MIT souhaitait abandonner la gestion de X, mais lors d'une réunion en juin 1987 avec neuf fournisseurs, ces derniers ont déclaré au MIT qu'ils croyaient en la nécessité d'une partie neutre pour empêcher la fragmentation de X sur le marché. En janvier 1988, le MIT X Consortium s'est constitué en tant que groupe de fournisseurs à but non lucratif, avec Scheifler comme directeur, pour diriger le développement futur de X dans une atmosphère neutre incluant les intérêts commerciaux et éducatifs.

Jim Fulton a rejoint l'équipe en janvier 1988 et Keith Packard en mars 1988 en tant que développeurs senior , Jim se concentrant sur Xlib , les polices , les gestionnaires de fenêtres et les utilitaires ; et Keith réimplémentant le serveur. Donna Converse, Chris D. Peterson et Stephen Gildea ont rejoint l'équipe plus tard cette année-là, se concentrant sur les boîtes à outils et les ensembles de widgets, travaillant en étroite collaboration avec Ralph Swick du projet Athena du MIT. Le MIT X Consortium a produit plusieurs révisions importantes de X11, la première (version 2 - X11R2) en février 1988. Jay Hersh a rejoint l'équipe en janvier 1991 pour travailler sur les fonctionnalités PEX et X113D. Il a été suivi peu après par Ralph Mor (qui a également travaillé sur PEX) et Dave Sternlicht. En 1993, alors que le MIT X Consortium se préparait à quitter le MIT, l'équipe a été rejointe par R. Gary Cutbill, Kaleb Keithley et David Wiggins.

En 1993, le X Consortium, Inc. (une société à but non lucratif) a été formé pour succéder au MIT X Consortium. Il a publié X11R6 le 16 mai 1994. En 1995, il a pris en charge le développement de la boîte à outils Motif et de l' environnement de bureau commun pour les systèmes Unix. Le Consortium X s'est dissous à la fin de 1996, produisant une révision finale, X11R6.3, et un héritage d'influence commerciale croissante dans le développement.

En janvier 1997, le Consortium X a transmis la gestion de X à The Open Group , un groupe de fournisseurs formé début 1996 par la fusion de l' Open Software Foundation et de X/Open .

L'Open Group a publié X11R6.4 au début de l'année 1998. De manière controversée, X11R6.4 s'est éloigné des termes de licence traditionnels et libéraux, car l'Open Group cherchait à assurer le financement du développement de X, et a spécifiquement cité XFree86 comme ne contribuant pas de manière significative à X. Les nouveaux termes auraient fait de X un logiciel non libre : gratuit pour une utilisation non commerciale, mais payant dans le cas contraire. Après que XFree86 ait semblé prêt à se lancer dans un fork , l'Open Group a re-licencié X11R6.4 sous la licence traditionnelle en septembre 1998. La dernière version de l'Open Group est venue sous la forme du patch 3 de X11R6.4.

XFree86 est né en 1992 du serveur X386 pour IBM PC compatibles inclus avec X11R5 en 1991, écrit par Thomas Roell et Mark W. Snitily et offert au MIT X Consortium par Snitily Graphics Consulting Services (SGCS). XFree86 a évolué au fil du temps, passant d'un simple portage de X à l'implémentation la plus populaire et la plus importante et au standard de facto du développement de X.

En mai 1999, The Open Group a formé X.Org. X.Org a supervisé la publication des versions X11R6.5.1 et suivantes. Le développement de X à cette époque était devenu moribond ; la plupart des innovations techniques depuis la dissolution du Consortium X avaient eu lieu dans le projet XFree86. En 1999, l'équipe XFree86 a rejoint X.Org en tant que membre honoraire (non payant), encouragée par diverses sociétés de matériel intéressées par l'utilisation de XFree86 avec Linux et par son statut de version la plus populaire de X.

En 2003, alors que la popularité de Linux (et donc de la base installée de X) a augmenté, X.Org est resté inactif, et le développement actif a eu lieu principalement au sein de XFree86. Cependant, une dissension considérable s'est développée au sein de XFree86. Le projet XFree86 a souffert d'une perception d'un modèle de développement beaucoup trop cathédral ; les développeurs ne pouvaient pas obtenir d'accès CVS commit et les fournisseurs devaient maintenir des ensembles de correctifs étendus . En mars 2003, l'organisation XFree86 a expulsé Keith Packard, qui avait rejoint XFree86 après la fin du consortium X du MIT original, avec un sentiment de ressentiment considérable.

X.Org et XFree86 ont commencé à discuter d'une réorganisation adaptée pour favoriser correctement le développement de X. Jim Gettys avait fortement poussé pour un modèle de développement ouvert depuis au moins 2000. Gettys, Packard et plusieurs autres ont commencé à discuter en détail des exigences pour une gouvernance efficace de X avec un développement ouvert.

Enfin, dans un écho au conflit de licence X11R6.4, XFree86 a publié la version 4.4 en février 2004 sous une licence plus restrictive que de nombreux projets s'appuyant sur X ont jugé inacceptable. La ​​clause ajoutée à la licence était basée sur la clause publicitaire de la licence BSD originale, qui était considérée par la Free Software Foundation et Debian comme incompatible avec la GNU General Public License . D'autres groupes la considéraient comme contraire à l'esprit de la licence X originale. Theo de Raadt d' OpenBSD , par exemple, a menacé de forker XFree86 en invoquant des problèmes de licence. Le problème de licence, combiné aux difficultés à faire des changements, a laissé beaucoup de gens penser que le moment était venu de forker.

Début 2004, plusieurs personnes de X.Org et de freedesktop.org ont formé la Fondation X.Org et l'Open Group lui a donné le contrôle du x.org nom de domaine . Cela a marqué un changement radical dans la gouvernance de X. Alors que les administrateurs de X depuis 1988 (y compris l'ancien X.Org) étaient des organisations de fournisseurs, la Fondation était dirigée par des développeurs de logiciels et utilisait le développement communautaire basé sur le modèle du bazar , qui repose sur l'implication extérieure. L'adhésion était ouverte aux particuliers, l'adhésion des entreprises se faisant sous forme de parrainage. Plusieurs grandes entreprises telles que Hewlett-Packard soutiennent actuellement la Fondation X.Org.

La Fondation a un rôle de supervision sur le développement de X : les décisions techniques sont prises en fonction de leurs mérites en parvenant à un consensus approximatif entre les membres de la communauté. Les décisions techniques ne sont pas prises par le conseil d'administration ; en ce sens, elle est fortement calquée sur la Fondation GNOME, techniquement non interventionniste . La Fondation n'emploie aucun développeur. La Fondation a publié X11R6.7, le serveur X.Org , en avril 2004, basé sur XFree86 4.4RC2 avec les modifications de X11R6.6 fusionnées. Gettys et Packard avaient repris la dernière version de XFree86 sous l'ancienne licence et, en mettant l'accent sur un modèle de développement ouvert et en conservant la compatibilité GPL, ont intégré à bord de nombreux anciens développeurs de XFree86.

Bien que X11 ait reçu des extensions telles que le support OpenGL au cours des années 1990, son architecture est restée fondamentalement inchangée au cours de la décennie. Au début des années 2000, cependant, il a été révisé pour résoudre un certain nombre de problèmes qui avaient fait surface au fil des ans, notamment une architecture de polices « défectueuse » , un système graphique 2D « qui avait toujours été destiné à être augmenté et/ou remplacé », et des problèmes de latence . X11R6.8 est sorti en septembre 2004. Il a ajouté de nouvelles fonctionnalités importantes, notamment la prise en charge préliminaire des fenêtres translucides et d'autres effets visuels sophistiqués, des agrandisseurs d'écran et des miniatures, et des fonctionnalités d'intégration avec des systèmes d'affichage immersifs 3D tels que le projet Looking Glass de Sun et le projet Croquet . Des applications externes appelées gestionnaires de fenêtres de composition fournissent une politique pour l'apparence visuelle.

Le 21 décembre 2005, X.Org a publié X11R6.9, l' arborescence source monolithique pour les utilisateurs hérités, et X11R7.0, le même code source séparé en modules indépendants, chacun maintenable dans des projets séparés. La Fondation a publié X11R7.1 le 22 mai 2006, environ quatre mois après 7.0, avec des améliorations de fonctionnalités considérables.

Le développement de XFree86 s'est poursuivi pendant quelques années encore, la version 4.8.0 étant publiée le 15 décembre 2008.

Les noms appropriés du système sont répertoriés dans la page de manuel comme X ; X Window System ; X Version 11 ; X Window System, Version 11 ; ou X11.

Le terme « X-Windows » (à la manière de « Microsoft Windows » publié ultérieurement) n'est pas officiellement approuvé – le responsable de la publication du Consortium X, Matt Landau, déclarant en 1993 : « Il n'existe pas de chose telle que « X Windows » ou « X Window », malgré l'utilisation répétée et abusive de ces formes par les journaux spécialisés » – bien qu'il ait été d'un usage informel courant depuis le début de l'histoire de X et ait été utilisé délibérément pour un effet provocateur, par exemple dans le Manuel des ennemis d'Unix .

Le système X Window utilise de manière nuancée un certain nombre de termes par rapport à l'usage courant, en particulier « affichage » et « écran », dont un sous-ensemble est donné ici pour plus de commodité :

appareil

Un périphérique graphique tel qu'une carte graphique d'ordinateur ou le chipset graphique intégré d'une carte mère d'ordinateur.

moniteur

Un périphérique physique tel qu'un écran cathodique ou un écran plat d'ordinateur.

écran

Zone dans laquelle les graphiques peuvent être rendus, soit par logiciel seul dans la mémoire système comme avec VNC , soit dans un périphérique graphique, dont certains peuvent être rendus sur plusieurs écrans simultanément, soit visualisables simultanément, soit de manière interchangeable. Les écrans interchangeables sont souvent configurés pour être théoriquement à gauche et à droite l'un de l'autre, passant de l'un à l'autre lorsque le pointeur de la souris atteint le bord de l'écran.

écran virtuel

Deux significations différentes sont associées à ce terme :

• Une technique permettant de déplacer un moniteur autour d'un écran fonctionnant à une résolution plus grande que celle actuellement affichée par le moniteur.
• Un effet simulé par un gestionnaire de fenêtres en conservant les informations de position de la fenêtre dans un système de coordonnées plus grand que l'écran et en permettant un panoramique en déplaçant simplement les fenêtres en réponse à l'utilisateur.

afficher

Ensemble d'écrans, impliquant souvent plusieurs moniteurs, généralement configurés pour permettre à la souris de déplacer le pointeur vers n'importe quelle position à l'intérieur de ceux-ci. Les postes de travail basés sur Linux sont généralement capables d'avoir plusieurs écrans, parmi lesquels l'utilisateur peut basculer avec une combinaison de touches spéciale telle que Ctrl-Alt -Touche de fonction , faisant basculer simultanément tous les moniteurs de l'affichage des écrans d'un écran vers les écrans d'un autre.

Le terme « écran » ne doit pas être confondu avec le jargon plus spécialisé « écran Zaphod ». Ce dernier est une configuration rare permettant à plusieurs utilisateurs d'un même ordinateur de disposer chacun d'un ensemble indépendant d'écran, de souris et de clavier, comme s'ils utilisaient des ordinateurs distincts, mais à un coût par poste inférieur.

En ce qui concerne les futures versions, le site Web de X.org indique :

X.Org continue de développer et de publier les composants logiciels du système X Window.

Ceux-ci sont publiés individuellement au fur et à mesure que chaque composant est prêt, sans attendre un calendrier de publication global « katamari » du système X Window - consultez le répertoire des versions individuelles de X.Org pour les téléchargements, et les archives xorg-announce ou les référentiels git pour plus de détails sur les modifications incluses.

Aucun plan de publication pour une version cumulative de Katamari X11R7.8 n'a été proposé.