X11R7.5 publié. Certes, mais encore ?

Posté par  . Modéré par Mouns.
Étiquettes :
42
28
oct.
2009
Serveurs d’affichage
Récemment tiwaz nous parlait de la sortie (à venir à ce moment là) de X11R7.5. Aujourd'hui c'est chose faite et je me propose à cette occasion de revenir sur le projet X.org à travers la traduction d'un article publié par l'un de ses hackers.
La conclusion est néanmoins de mon cru et les réflexions associées n'engagent que moi.

Cette dépêche est donc une traduction intégrale, avec son aimable autorisation, d'un article de Peter Hutterer, un développeur impliqué dans le projet X.org et en particulier derrière X Input. 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 forment « X Window System ».

X Protocol
Le composant au cœur 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 1980 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.
X Server implémente le protocole cœur et la plupart de ses extensions, mais différents X Servers peuvent implémenter différentes versions. Globalement, le X Server le plus récent 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 et 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 une 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 du blog de Peter Hutterer ---

Ma 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.

Aller plus loin

  • # Et la libc ?

    Posté par  (site web personnel) . Évalué à 10.

    X.org est sans doute l'élément le plus critique après le noyau pour l'utilisation au quotidien d'un bureau Linux.

    On oublie très souvent la libc. C'est pas quelque chose de très visible, mais c'est pourtant indispensable...

    • [^] # Re: Et la libc ?

      Posté par  . Évalué à 4.

      Je dirais que
      1) le posteur exagère pour le role d'X, ce n'est pas la seule couche graphique pour Linux, il y a DirectFB il me semble par exemple (sans acceleration graphique si ma mémoire est bonne: bof!)

      2) Tu pinaille.. Ldd, les shells, les toolkits: tout les éléments de la chaines sont quasiment indispensables..

      • [^] # Re: Et la libc ?

        Posté par  (site web personnel) . Évalué à 3.

        A la différence que tous les éléments autres que le noyaux ne peuvent pas fonctionner sans libc, c'est ce que le premier commentaire précisait.

        • [^] # Re: Et la libc ?

          Posté par  . Évalué à 4.

          Ce n'est pas exact.
          La plupart des programmeurs choisissent d'utiliser la libc. Mais ce n'est pas une obligation. On peut très bien utiliser autre chose à la place. Il "suffit" de l'avoir.

          La libc semble très bien remplir son rôle, et donc presque tout le monde l'utilise. Mais il existe des dérivés adaptés en particulier aux petites machines.

      • [^] # Re: Et la libc ?

        Posté par  . Évalué à 3.

        Le fait est qu'en effet Xorg n'est pas la seule couche graphique pour Linux (et je ne prend pas en compte le monde l'embarqué, par ex : Qt extended improved utilisé par le projet OpenMoko). Mais Xorg n'est pas non plus qu'une couche graphique, c'est un "window system".

        En plus de l'affichage (et donc du dessin effectif à l'écran) de tous les 'trucs" imaginables dont une application peut avoir besoin, Xorg prend en charge un certain nombre d'autres choses : le concept de fenêtre et ce qui en découle (le focus par exemple), les entrées et la redirection des événements d'entrée, la gestion des écrans...

        Le framebuffer et bien n'est finalement que ça : une zone de la mémoire (buffer) dont la taille correspond à la résolution de l'écran (frame) dans laquelle on "dessine".

        • [^] # Re: Et la libc ?

          Posté par  . Évalué à 3.

          Le concept de fenêtre, ce n'est pas tant X que le WM, en fait. Pour X, "tout" ce qui est vaguement rectangulaire est une fenêtre, et pas seulement les "toplevels" (qui correspondent à l'acception courante du terme en informatique).

          Le gros plus de X par rapport à un framebuffer tout simple, c'est le fait de gérer plusieurs clients/applications.

          • [^] # Re: Et la libc ?

            Posté par  . Évalué à 1.

            Le gros plus de X par rapport à un framebuffer tout simple, c'est le fait de gérer plusieurs clients/applications.

            Je suis d'accord
            X est le seul truc que je connais qui gère en bas niveau un concept client/serveur graphique avec couche réseau.
            J'ai régulièrement constaté que les gens critiquent les performances de Xorg, et négligent tout ce qu'il apporte en terme de souplesse et de fonctionnalité.

            Enfin, si le projet manque de visibilité, c'est aussi parce que l'élément n'est pas directement visible (l'utilisateur voit gnome/kde/compiz), à l'instar d'un noyau ou d'un gcc
            Par ailleurs, tout le travail actuel semble être composé de retouches structurelles, d'ajout des pilotes et api gnu modernes , sur un code datant des années 80 et extrêmement bien conçu

    • [^] # Re: Et la libc ?

      Posté par  . Évalué à 10.

      On oublie très souvent la libc. C'est pas quelque chose de très visible, mais c'est pourtant indispensable...

      Ça ressemble un peu à de l'auto-pub ça, venant du mainteneur Debian de ladite libc :)

    • [^] # Re: Et la libc ?

      Posté par  . Évalué à 4.

      Loin de moi l'idée de dénigrer une pièce des système Linux, mais de mon point de vu d'utilisateur lambda-mais-pas-tout-à-fait, c'est vrai que j'assimile (un peu trop ?) facilement la libc au noyau même si ce sont pourtant deux morceaux bien distinct.

      En plus, je suis beaucoup plus intéressé par les développements que connait Xorg que par le monde (obscur s'il en est) de la libc, auquel je ne pane strictement rien.

      • [^] # Re: Et la libc ?

        Posté par  . Évalué à 2.

        Oui mais même si la libc est utilisée par 99,9% des logiciels, je pense que Xorg reste bien plus complexe et compliqué que la libc.
        La libc n'est qu'une collection de fonctions (printf, malloc pour n'en citer que 2 très connues) enfin je crois. Xorg est un vrai bazar.
        Merci pour cette traduction d'ailleurs, j'y vois un peu plus clair.

      • [^] # Re: Et la libc ?

        Posté par  . Évalué à 10.

        En plus, je suis beaucoup plus intéressé par les développements que connait Xorg que par le monde (obscur s'il en est) de la libc, auquel je ne pane strictement rien.

        Pour la libc le processus de développement est toujours le même, et reste assez simple (juste 2 étapes en fait) :
        - quelqu'un envoie un patch pour la libc
        - le patch est refusé par le mainteneur

        • [^] # Re: Et la libc ?

          Posté par  (site web personnel) . Évalué à 2.

          Il n'y a pas que glibc dans la vie. Il y en a d'autre, comme celle a laquelle debian va passer, et les libc incluses dans les *BSD

    • [^] # Re: Et la libc ?

      Posté par  . Évalué à 6.

      On oublie très souvent la libc.

      Non, non, non, ils pensent encore à elle : http://www.pafoo.net/uninstallglibc/uninstglibc.html

      • [^] # Re: Et la libc ?

        Posté par  (site web personnel) . Évalué à 1.

        Je précise pour les newbe qui passe dans le coin, que le howto cité plus haut décrit comme rapidement détruire complètement son installation linux. Suivre ce qui est marqué entraine ensuite une réinstallation complète (réparer à la main est beaucoup plus complexe que tout casser).

        "La première sécurité est la liberté"

        • [^] # Re: Et la libc ?

          Posté par  . Évalué à 3.

          pour la petite anecdote, j'ai un collegue pas linuxien pour 2 sous qui a reussi a foutre en l'air son serveur de test comme ca, tout seul comme un grand.

          Il lui fallait une version de libc superieur a celle de sa red hat, il a donc ete telecharge le premier rpm qu'il a trouve, a galere comme un chien pour desinstaller sa libc, puis s'est dit que ca serait plus propre de rebooter avant de reinstaller la nouvelle.
          Paf le serveur.

  • # XFree86

    Posté par  (site web personnel) . Évalué à 1.

    http://www.xfree86.org/cvs/changes.html

    Quand je regarde ça, je suis perplexe, qui utilise encore XFree86?

    Les vieux Unix?

    • [^] # Re: XFree86

      Posté par  . Évalué à 5.

      Euh, il parle de X11 pas de XFree, donc, si je ne m'abuse, tous les Xorg sont concernés...

  • # Petite erreur

    Posté par  . Évalué à 3.

    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, voir à 7.0).

    Tout à la fin, ça devrait être voire.

    • [^] # Re: Petite erreur

      Posté par  (site web personnel) . Évalué à 8.

      Corrigée (et quelques petites autres), j'en ai profité pour wikipédifier un peu aussi ;-)

      En tout cas, c'est cool d'avoir ce genre de dépêches informative, ne pas hésiter à en soumettre : même s'il y a quelques coquilles, les relecteurs sont là pour les corriger.
      Si certains se sentent l'envie et ont besoin d'un wiki pour la préparer collaborativement, ne pas hésiter à utiliser http://demoll.tuxfamily.org/linuxfr/NewsLinuxFr et à signaler le début de rédaction sur l'espace rédacteurs http://linuxfr.org/redacteurs/ (faut pas oublier de la poster une fois terminée, hein ! En plus, ça rapporte du karma :D)

      • [^] # Re: Petite erreur

        Posté par  . Évalué à 2.

        Mes excuses pour les erreurs, malgré le passage du correcteur orthographique et une relecture attentive on efface pas 25 ans de cancre-attitude syntaxique !

        Et merci c'est une bonne piste le wiki !

        (PS : ça sert à quoi le karma ? J'ai découvert ça dans le mail d'info d'acceptation)

        • [^] # Re: Petite erreur

          Posté par  (site web personnel) . Évalué à 6.

          (PS : ça sert à quoi le karma ? J'ai découvert ça dans le mail d'info d'acceptation)

          c'est une info à laquelle tu n'as pas accès (sinon ça prêterait à des jeux de celui qui a le plus gros), mais qui joue sur ton nombre de votes/avis, la note par défaut des commentaires des journaux quand tu les postes, la note par défaut de tes propres commentaires... Plus de détail sur :
          http://demoll.tuxfamily.org/linuxfr/SuggestionsLecteurLinuxF(...)

          Actuellement, par exemple :
          # Moyenne: 4.12 / 17 : 2
          # XP: 263/16/15
          la moyenne de tes 17 commentaires est à 4.12, tu postes avec une note par défaut de 2
          ton karma (XP) est actuellement de 263 ce qui fait que tu as 16 avis par jour (il t'en reste 15 à utiliser).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.