Discussion :

[Marvell]

Bonjour,
Je souhaiterais connaître des références (ouvrages ou sites internets) expliquant le fonctionnement de X11, ou plus généralement les environnements graphiques (comment sont-ils construits) avec, du moins en partie, explication du code source.
J'ai de bonnes connaissances, mais surtout au niveau des noyaux des systèmes d'exploitation… et j'aimerais vraiment apprendre comment fonctionne les environnements graphiques…
Merci d'avance pour vos réponses.

[Obsidian]

Bonjour,

Tu peux déjà regarder ici :
http://buffa.developpez.com/xwindow/
http://pficheux.free.fr/articles/lmf/xlib/

Le principe de X-Window en particulier est relativement simple :

• Il s'agit d'une application ordinaire, qui tourne pour sa majeure partie en mode user et pas en kernel, sauf pour quelques modules gérant la carte vidéo ;
• Elle est indépendante du système d'exploitation sur lequel elle tourne ;
• Cette application est en réalité un serveur : des applications externes s'y connectent et envoient des ordres graphiques dont le rendu se fait à l'écran ;
• Ces applications peuvent donc être exécutées sur une machine différente de celle qui gère l'affichage à l'écran.

Donc, toutes les applications se connectent en fait à une sorte de serveur de chat centralisé (le serveur X). De là, l'environnement est commun à toutes. Il fonctionne avec un système de fenêtres imbriquées, chacune d'entre elles s'inscrivant à l'intérieur de sa fenêtre-mère, la première d'entre toutes étant la fenêtre racine (root) qui couvre tout l'écran, exactement. L'évolution de cet environnement est émulé par un système d'événements que l'on retrouve dans pratiquement tous les autres environnements graphiques : mouvement souris, clic bouton, appui clavier, survol d'une fenêtre, etc. Ces événements peuvent se propager à tous les éléments père ou fils de celui qui en est à l'origine, et on peut demander à être à l'écoute de certains événements seulement, grâce à un système de masque.

On retrouve ce principe dans de nombreux environnements ou plateformes, comme le Javascript.

Les événements eux-mêmes sont relativement bien conçus pour un système de cet âge. Il s'agit d'authentiques objets, représentés chacun par une structure qui en contient tous les attributs et débutant à chaque fois par un même membre commun « type », le tout réuni dans une grosse « union ».

Comme, pour exploiter un serveur X, il faut être capable de parler son langage et de tenir la trace des objets qu'on y a déclarés, toutes les applications graphiques sont liés localement à la X-lib, qui sert à cela et qui proposent tous les primitives nécessaires pour le faire.

Autre avantage : si la connexion se referme et que ton application n'est pas prévue pour, tu recevras automatiquement un SIGPIPE de la part du système qui tuera ton application. Même chose côté serveur : sur réception d'un tel signal, ta connexion sera refermée et tous les objets que tu y auras créés seront détruits par défaut.

Enfin, pour lever une petite ambiguïté sur les termes « client » et « serveur » : c'est bien le serveur X qui est à l'écoute des connexions et qui reçoit des appels de différentes applications sur différentes machines. Et ce sont donc bien les applications qui sont clientes. Cela dit, le serveur X effectue le rendu sur la machine sur laquelle il fonctionne… qui est en principe le poste de travail de l'utilisateur — qu'on a tendance à considérer comme machine cliente — et , lorsque l'on utilise des thin clients, les applications fonctionnent sur un hôte centralisé à l'abri dans une salle machine, hôte que l'on nomme communément serveur.

[Marvell]

Merci beaucoup de ta réponse
Si j'ai bien compris, c'est une communication client-serveur "banale"… un système mis en place pour répondre aux besoins de puissance que ne disposaient pas les premiers ordinateurs ! Mais maintenant, client et serveur tournent sur la même machine… jusque là, aucun problème !
Mais ce que je souhaiterai comprendre, ce n'est pas tant la façon dont les programmes communiquent avec le serveur (bien que je ne sois pas contre une explication…), c'est surtout comment X communique avec le GPU !

Par exemple, prenons une carte VGA quelconque. J'imagine que le rôle d'X n'est pas d'écrire chaque bit de la mémoire vidéo (assuré par les drivers vidéos, tout comme certaines opérations "bas niveau" si je ne m'abuse…), mais de communiquer avec les programmes, gérer l'affichage (Xlib) et les événements (en se basant sur l'OS, puisque c'est un programme "quelconque", mais aussi directement sur les drivers) !?

Question : cela fonctionne t-il ainsi décrit ci-après ?

• Il se base sur des éléments graphiques (boutons, icônes, etc. aux formats .png, etc.) qu'il assemble comme un puzzle, afin de constituer l'interface graphique.

• Il "associe" à certains pixels une action (e.g. : bouton fermer) qu'il lie à un événement (dans notre exemple, fermer le programme).

• Il interagit avec les programmes et l'OS pour "lier" le "visible" et "l'invisible" (e.g. : il faut lier l'événement "fermer le programme" avec l'appel système correspondant ; la fenêtre disparaît de l'écran, le programme est fermé, "évincé" de la mémoire).

[Obsidian]

Merci beaucoup de ta réponse Si j'ai bien compris, c'est une communication client-serveur "banale"… un système mis en place pour répondre aux besoins de puissance que ne disposaient pas les premiers ordinateurs ! Mais maintenant, client et serveur tournent sur la même machine… jusque là, aucun problème !

Oui, mais pas seulement : le principe d'un serveur graphique a beaucoup d'avantages, comme le fait d'être totalement indépendant du système comme on l'a dit, et donc d'être entièrement débrayable sans risquer de mettre ledit système dans un état inutilisable. À dire vrai, les systèmes Unix SysV sont généralement configurés pour lancer X-Windows en level 5 et ne pas le lancer en level 3, avec pour ainsi dire aucune autre différence entre les deux. Et il n'y a pas très longtemps, les distribs Linux ne démarraient même pas X-Window automatiquement : on faisait « startx » pour lancer le script qui initialisait tout cela sans douleur.

D'autre part, le modèle thin client et mainframe est encore très utilisé même de nos jours. Ça permet de donner aux utilisateurs un accès facile à un grand nombre de machines différentes, ou à des machines spécialisées, surtout lorsqu'elles sont hétérogènes, par exemple des machines Unix et Windows. Ce dernier système utilise Terminal Server, RDP ou Citrix ICA, même si le fonctionnement de ces technologies est assez différent.

Mais ce que je souhaiterai comprendre, ce n'est pas tant la façon dont les programmes communiquent avec le serveur (bien que je ne sois pas contre une explication…),

Ils le font via des appels aux fonctions de la X-Lib qui, elle, traduit cela dans le protocole de communication approprié.

c'est surtout comment X communique avec le GPU !

Ça, par contre, c'est à la discrétion du serveur, et ça peut être implémenté de plusieurs façons différentes selon le serveur X utilisé. La seule chose qu'il faut garder à l'esprit, c'est que comme il le fait de manière indépendante du système, il utilise ses propres pilotes vidéo.

En principe, ce n'est pas le rôle d'un kernel de gérer ces choses-là, donc ça ne pose pas de problème. En pratique, les noyaux récents sont faits pour tourner sur des machines récentes et les noyaux tels que Linux proposent le frame buffer, qui est capable de prendre en charge les grandes familles de carte vidéo et de les exploiter un peu plus loin que le mode texte. Les noyaux et les serveurs X se connaissent depuis suffisamment longtemps pour pouvoir travailler en parallèle sans se marcher sur les pieds, mais quand on ne le sait pas, ça rend perplexe de voir quelque chose être géré par le noyau et pas par le serveur graphique, et reciproquement.

Cela dit, dans les faits, le pilote en question est, par nature, fondamentalement de bas niveau et prend donc la forme d'un module du noyau. Il se peut aussi que le serveur X travaille avec des modes standard tels que SVGA et n'ait donc pas spécialement besoin de pilote, mais ça devient rare aujourd'hui.

Évidemment, s'il faut faire un appel à chaque fois que l'on veut tracer un pixel à l'écran et que cet appel est lui-même traduit en une transaction réseau, elle-même interprétée par le serveur, le tout va être relativement lent. La plupart du temps, ce n'est pas un problème. La X-lib est capable d'optimiser tout cela et d'utiliser par exemple des sockets Unix locaux plutôt qu'une vraie communication réseau lorsque c'est possible.

Par contre, si c'est un jeu vidéo que l'on veut faire, l'application elle-même doit avoir accès à la mémoire vidéo pour la gérer elle-même, utiliser les éventuels blitters à sa disposition, etc. Dans ce cas, le serveur X lui-même n'a plus grand chose à faire lui-même, si ce n'est maintenir la position de la fenêtre et assurer la séparation avec les autres. Pour permettre à de telles applications d'obtenir un accès direct, on a défini des infrastructures « officielles » comme DRI : http://fr.wikipedia.org/wiki/Direct_...Infrastructure

Cette facilité va être elle-même exploitée par les routines de rendu 3D qui, elles, répondent par exemple à l'API d'OpenGL.

Évidemment, ceci n'est possible que si le serveur et l'application concernée tournent sur la même machine, ce qui est généralement le cas aujourd'hui. Dans le cas contraire, soit l'application échoue (impossible d'utiliser DRI), soit la Xlib se rabat automatiquement sur le mode normal. C'est alors extrêmement lent, mais le rendu se fait quand même.

Par exemple, prenons une carte VGA quelconque. J'imagine que le rôle d'X n'est pas d'écrire chaque bit de la mémoire vidéo (assuré par les drivers vidéos, tout comme certaines opérations "bas niveau" si je ne m'abuse…), mais de communiquer avec les programmes, gérer l'affichage (Xlib) et les événements (en se basant sur l'OS, puisque c'est un programme "quelconque", mais aussi directement sur les drivers) !?

En fait, si. Comme expliqué plus haut, le serveur X est une pile qui remplit tous ses services. Pour la Xlib, son rôle n'est pas de « gérer l'affichage » (c'est celui du serveur X lui-même, mais de permettre à une application lambda de communiquer avec ce serveur et de l'exploiter. C'est de la même façon que la libpq permet à un programme en C de dialoguer avec un serveur PostGreSQL, par exemple.

Question : cela fonctionne t-il ainsi décrit ci-après ?

• Il se base sur des éléments graphiques (boutons, icônes, etc. aux formats .png, etc.) qu'il assemble comme un puzzle, afin de constituer l'interface graphique.

• Il "associe" à certains pixels une action (e.g. : bouton fermer) qu'il lie à un événement (dans notre exemple, fermer le programme).

• Il interagit avec les programmes et l'OS pour "lier" le "visible" et "l'invisible" (e.g. : il faut lier l'événement "fermer le programme" avec l'appel système correspondant ; la fenêtre disparaît de l'écran, le programme est fermé, "évincé" de la mémoire).

C'est encore plus sympa que cela : les « fenêtres » déclarées ne sont que des zones à l'écran, rectangulaires et invisibles. Le serveur sait que toute requête graphique s'appliquant en dehors de cette zone doit être ignorée de manière silencieuse. Donc, un simple bouton dispose en fait de sa propre fenêtre. Les événements, comme un clic sur ce bouton, ne sont effectivement émis que si le curseur se trouve dans une de ces zones.

Et c'est là qu'intervient une des merveilles de cette architecture : les Window Managers. En substance, c'est une application tierce et tournant au même niveau que la tienne qui va surveiller les événements qui va dessiner les décorations systèmes autour des fenêtres (celles dont tu as l'habitude, cette fois) que tu auras déclarées. Et ce qu'il y a de très fort avec ce système, c'est que si tu fermes un Window Manager pour en ouvrir un autre, alors tu vois toutes tes fenêtres se déshabiller sans être fermées puis être redécorées d'une manière différente, sans que les applications qui sont derrières s'en trouvent perturbées.

Par contre, « fermer le programme » n'est pas un événement. C'est un ordre. Et ça ne relève absolument pas du serveur X. Le serveur fait état d'un clic éventuel dans une des fenêtres ouvertes par ton application. Si cette fenêtre héberge un bouton de fermeture, c'est à ton programme d'agir en conséquence. Toutefois, la bibliothèque te permet quand même d'associer une callback pour que cela se fasse tout seul.

Ensuite, X-Window va communiquer avec ton programme mais pas « interagir avec l'OS » (sauf à la limite au niveau des pilotes vidéos et du choix par l'utilisateur de la console virtuelle en cours d'utilisation).

Et surtout, ce n'est pas X-Window qui va fermer ton programme de force et l'évincer de la mémoire. Surtout pas, à plus forte raison, s'il ne se trouve même pas sur la même machine que l'environnement ! Par contre, il peut effectivement refermer la connexion de force si on lui demande. Et si ça arrive et que ce n'est pas prévu par l'application, alors la perte de connexion va automatiquement engendrer un signal SIGPIPE de la part du système et ce signal aura pour effet par défaut de tuer l'application. Ce qui fait que le ménage se fait tout seul si l'application n'est pas assez mature pour le faire elle-même.

D'autre part, cette infrastructure cloisonnée a un avantage de taille, par rapport à un système plus coopératif comme on en trouvait sous Windows : une application qui ne répond plus ne peut jamais « freezer » le serveur X même si elle est en plein écran. Ce qui relève de sa responsabilité ne sera effectivement plus rafraîchi, mais les décorations systèmes gérées par le Window Manager et les autres fenêtres ne seront nullement affectées.

Pour terminer, le serveur X et la X-lib proposent un système de fenêtrage et quelques primitives graphiques. Ils ne dessinent pas les boutons et les autres widgets eux-mêmes. C'est pourquoi, plusieurs autres bibliothèques telles que GTK s'appuient sur la X-lib et font cela pour toi. Elles limitent même le nombre de fenêtres déclarées auprès du serveur X en gérant le zonage elles-mêmes. Par ailleurs, comme ils s'agit de projets indépendants, elles font complètement abstraction de la X-lib elle même aux yeux du programmeur, pour pouvoir éventuellement fonctionner sur d'autres plateformes (GTK a été porté sous Windows).

C'est pourquoi la programmation X-lib proprement dite est doucement tombée en désuétude au profit de développement sous GTK ou Qt par exemple, même si les principes sont exactement les mêmes et que, pour la plupart, ces bibliothèques se contentent de transmettre les requêtes du programmeur directement ou presque à la Xlib.

[Marvell]

Merci beaucoup pour ces précisions
Deux dernières questions (et après je ne t'embete plus ) :

• Je croyais que X faisait des appels système, par exemple pour fermer un programme (ce qui me semble logique). Or tu me dis
  

  Par contre, « fermer le programme » n'est pas un événement. C'est un ordre. Et ça ne relève absolument pas du serveur X. Le serveur fait état d'un clic éventuel dans une des fenêtres ouvertes par ton application. Si cette fenêtre héberge un bouton de fermeture, c'est à ton programme d'agir en conséquence.

  C'est donc au programme de gérer les ordres (l'exemple que j'avais pris était la fermeture du programme) !?

• Question "pratique" : saurais-tu où trouver de la doc sur le code source de X ; parce que, comme tous (ou presque), le code n'est pas vraiment documenté…

[Obsidian]

Je croyais que X faisait des appels système, par exemple pour fermer un programme (ce qui me semble logique). Or tu me dis C'est donc au programme de gérer les ordres (l'exemple que j'avais pris était la fermeture du programme) !?

Bien sûr. D'abord parce qu'un « appel système », c'est l'utilisation par un programme d'une des primitives du système d'exploitation, qui sont en nombre limité et qui se traduisent en théorie par un appel au noyau. A priori, ça n'a rien à voir avec ce que l'on est en train de faire (même si, dans les faits, ton programme et le serveur X restent tous deux des applications et ont a y recourir, mais chacun de leur côté).

Ensuite, parce que comme on l'a dit, l'affichage graphique est un service complètement facultatif pour une application, qui n'en a absolument pas besoin en elle-même pour fonctionner. Le serveur X ne fait pas partie du système. Il fonctionne en mode utilisateur et n'a pas plus de droits sur ton processus que n'importe quel autre programme.

C'est un peu comme lorsque tu te connectes à un serveur de chat IRC : un autre connecté peut te dire « fiche le camp », mais libre à toi d'obéir ou pas. Bon, d'accord, il peut te kicker d'un canal et, dans le pire des cas, un Irc-Op peut te déconnecter de force en refermant ta connexion depuis le serveur, mais c'est le maximum qu'il puisse faire : ton client IRC t'indique alors que tu t'es fait mettre à la porte, mais l'Irc-Op en lui-même n'a pas le pouvoir de tuer ton client sur ta machine (sauf crack, bien sûr, mais c'est une autre histoire :-) ).

Et enfin, ce n'est absolument pas approprié puisque le serveur X ne sait pas en soi que telle ou telle fenêtre est en elle-même un bouton de fermeture ou pas. C'est l'application, encore une fois, qui alloue des fenêtres et des ressources sur le serveur X et qui y dessine ce qu'elle a envie.

Maintenant — et c'est important — il est fréquent, comme on l'a dit plus haut, que ton application fasse appel à des bibliothèques de plus haut niveau, comme GTK ou Qt et qui, elles, exploitent la Xlib à la place du programmeur et qui y dessinent automatiquement des boutons, etc. Ce sont alors ces mêmes bibliothèques qui vont surveiller les événements en provenance du serveur X et prendre des décisions en conséquence, comme quitter le programme. C'est ce qui peut te donner l'illusion que ces choses sont automatiques, voire provoquées par le serveur X, alors qu'il n'en est rien.

Question "pratique" : saurais-tu où trouver de la doc sur le code source de X ; parce que, comme tous (ou presque), le code n'est pas vraiment documenté…

La « doc du code source de X » ? Tu parles du code source du serveur X lui-même ou de la Xlib ?

Dans tous les cas, tu n'as besoin d'explorer le code source ni de l'un ni de l'autre pour coder : la X-lib est très bien documentée : chaque appel a sa propre man page qui doit être installée par défaut sur ta machine et les liens que je t'ai donnés au-dessus la détaillent chapitre par chapitre et propose même des exercices. Et s'ils ne te conviennent pas, il y a pléthore de pages sur Internet qui la détaillent en long et en large, ainsi que plusieurs ouvrages si tu préfères le papier.

Si tu tiens absolument à voir le code source, maintenant, tu peux l'avoir soit directement via les packages de la distribution que tu utilises, soit ici (pour X.org) : http://www.x.org/wiki/Documentation

[Marvell]

Merci beaucoup pour toutes ces précisions… ça m'a permi de mieux comprendre le rôle de X et son implémentation
Question personnelle : ou as-tu acquis ces connaissances sur X11 ?

[Obsidian]

Question personnelle : ou as-tu acquis ces connaissances sur X11 ?

Je les ai acquises seul. Cela dit, ce n'est pas bien difficile car la Xlib est assez bien pensée (à mon goût, en tout cas). Je travaille sous Linux depuis 1998 et, avant ça, j'utilisais d'autres environnements de travail. Au bout d'un moment, on développe le même esprit logique que les autres programmeurs et on finit par savoir d'instinct où chercher dans les grandes lignes.

Consulte les man pages. Sous leur aspect un peu austère, elles sont en fait le moyen le plus efficace d'avoir des infos sur un point précis. Elles sont souvent munies d'une section « See Also » en bas de page qui te cite rapidement les fonctions voisines de celle que tu utilises. Si tu sautes de page en page en les lisant, tu auras toutes les informations dont tu as besoin. Tu peux commencer avec « man XOpenDisplay ».

Consulte également ce site : http://www.u-picardie.fr/~ferment/xwindow/index.htm

Si tu arrives à faire abstraction du fond jaune, tu auras un cours avec des exercices sur la Xlib entière.

[Marvell]

Merci beaucoup pour ces réponses