Récemment X11R7.5 a été publié. Je me propose à cette occasion de revenir sur le projet X.org au travers d'une traduction d'un article publié par l'un des ses hackers. La conclusion est néanmoins de mon cru et les réflexions associées n'engage que moi.

Cette article est donc une traduction intégrale, avec son aimable autorisation, d'un article de Petter Hutterer, un développeur impliqué dans le projet X.org et en particulier derrière X Input.

Début de la traduction.

X11R7.5 publié. Certes, mais encore ?

Grâce aux efforts d'Alan Coppersmith, X11R7.5 a été publié il y a quelques jours. Qu'est ce que cela peut bien vouloir dire.

Ce billet vise à mettre en lumière les composants de X11R7.5 ainsi qu'à expliquer d'où proviennent leurs numéros de version.

X Window

Si vous utilisez un système d'exploitation différent de Microsoft Windows ou de Mac OS X, il est fort possible que vous utilisiez également X Window System, également appelé "X11" ou simplement "X". X consiste en un assemblage de plusieurs pièces, dont certaines sont plus visibles que d'autres, qui toutes ensembles sont "X Window System"?

X Protocol

LE composant d'X est le protocole X. Il définit X et est principalement une API. Dans ce qu'on appelle le protocole X, on distingue le protocole "cœur", qui date des années 80 et plusieurs extensions, essentiellement des additions au protocole cœur. Quand vous entendez parler de XInput, XRandR, RENDER, etc., ce sont des extensions.

X Server et les pilotes

X Server est le processus qui "discute" avec les pilotes et qui "écoute" les applications qui requièrent de dessiner des "trucs". C'est également lui qui récupère les événements d'entrée et les transmet à la bonne application. En fonction de votre matériel, vous utiliserez un certain nombre de pilotes. Actuellement, les pilotes généralement utilisés sont evdev et synaptics pour les entrées, et intel, ATI ou Nvidia pour la partie graphique.

C'est encore X Server qui implémente le protocole cœur et la plupart de ses extensions, différents X Servers pouvant implémenter différentes versions. Globalement, le plus récent X Server implémente la version la plus récente du protocole.

Xlib et compagnie

Xlib (parfois libX11) est la bibliothèque logicielle qui permet aux applications de "discuter" en X Protocol avec le X Server. Elle enrobe le protocole dans une API d'un peu plus haut niveau. Quasiment toutes les applications graphiques actuelles utilisent Xlib à un moment ou à un autre, Xlib est d'ailleurs abstraite par les toolkits graphiques, comme GTK ou Qt.

Xlib a été longtemps la seule bibliothèque à utiliser le procotole X mais depuis quelques années, XCB gagne du terrain (en fait les dernières versions de Xlib utilisent XCB pour ce qui relève du bas niveau).

Les applications X

Il y a de nombreuses applications qui font traditionnellement partie du X Window System. Parmi elles, le fameux xeyes, mais aussi des outils cruciaux comme setxkbmap ou xkbcomp.

Le reste

Il y a aussi, au sein du X Window System, nombre d'autres paquets qui comptent les polices de caractères, des outils divers, des données... Je passe sur les détails, il suffit juste de savoir qu'ils sont là.

X11R7.quoi ?

Si l'on revient en arrière de quelques années, tous ces composants étaient regroupés dans un unique dépôt. Et pour construire un seul d'entre eux, il fallait construire tous les autres. Pour en publier un, il fallait publier tous les autres. Avec le temps, les numéros de versions de cet arbre monolithique ont atteint 6.9.

X11R6.9 (X11 édition 6.9) fut la dernière publication unifiée. Vers 2005, l'arbre monolithique a été éclaté en plusieurs dépôts, un par composant. À ce moment là, les numéros de version ont également été remis à 1.0 pour la majeure partie des composants (ceux qui en étaient à 6.9, voire à 7.0).

Depuis, les publications X11.R7.x (appelée également katamari) sont très similaires aux distributions. Elles embarquent un des modules, chacun d'une certaine version et dont on sait qu'ils fonctionnent ensemble, et les regroupe en un seul jeu. Les modules en eux-même sont indépendants des katamaris et leurs numéros de version peuvent sauter entre les katamaris. Par exemple, X11R7.4 inclut X Server 1.5 mais pour X11R7.5 c'est X Server 1.7.

C'est une source de beaucoup de confusion. La plupart des utilisateurs ne savent pas s’ils utilisent 1.7, 7.5, 1.0 ou 6.8. Un katamari vise juste à fournir un jeu de composants suffisant pour faire tourner un GUI basique. C'est pourquoi avec le temps des modules ont disparu ou au contraire ont été introduits au sein des katamaris. Un module inclus dans X11R7.5 pourrait ne pas l'être dans X11R7.6 et réciproquement (la liste complète des modules et de leur version se trouve au début du journal des changements de X11R7.5).

Quelle version est importante ?

Les katamaris sont important principalement pour les distributeurs. Ils représentent un jeu de module d'une certaine version dont on sait qu'ils fonctionneront ensembles et en cela ils facilitent le packaging. Une distribution est libre de démarrer avec un katamari et d'inclure les nouvelles versions des modules au fur et à mesure de leur publication. Un katamari est un point de départ, rien de plus.

Pour ces raisons, il importe rarement aux utilisateurs finaux de savoir si un module qu'ils utilisent est inclus dans un katamari ou non. Pour les rapports de bug, les développeurs ont besoins des numéros de version des tous les modules impliqués afin de réduire leur champ d'investigation.

Pour connaître le numéro de version du X Server et des pilotes, il suffit de regarder au début du fichier /var/log/Xorg.0.log. La première ligne concerne le X Server. Comme les pilotes sont chargés dynamiquement, il faudra chercher dans le journal. Par exemple, le mien me dit :

X.Org X Server 1.7.0

...

(II) Module intel: vendor="X.Org Foundation"

      compiled for 1.6.99.903, module version = 2.9.0
      Module class: X.Org Video Driver
      ABI class: X.Org Video Driver, version 6.0

...

(II) Module evdev: vendor="X.Org Foundation"

      compiled for 1.7.0, module version = 2.3.0
      Module class: X.Org XInput Driver
      ABI class: X.Org XInput driver, version 7.0

...

(II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so (II) Module synaptics: vendor="X.Org Foundation"

      compiled for 1.6.99.900, module version = 1.1.99
      Module class: X.Org XInput Driver
      ABI class: X.Org XInput driver, version 7.0

J'utilise donc actuellement X server 1.7.0 avec evdev 2.3.0, intel 2.9.0 et synaptics 1.1.99. Que ces versions fassent ou non partie d'un katamari importe peu.

Les applications X ont habituellement un paramètre -version. Pour les bibliothèques, le mieux est d'utiliser le système de gestion des paquets de la distribution (par exemple rpm -q libX11) pour accéder au numéro de version.

Fin de la traduction.

Conclusion

X.org est sans doute l'élément le plus critique après le noyau pour l'utilisation au quotidien d'un bureau Linux. Le projet souffre pourtant d'un manque de visibilité (ce que je trouve ironiquement paradoxal pour un projet qui nous permet de voir nos applications...) et d'un manque de main d'œuvre important.

Je n'ai pas les compétences requises pour participer au développement de X, j'ai tout juste celle pour traduire les articles de ceux qui le font, c'est donc ma maigre contribution au projet que de les aider à communiquer sur le travail.

Pour en savoir plus :

Note au lecteur : Cette article a été également publier sur le site linuxfr.