10.1. Généralités sur XWindow

Il est nécessaire de bien comprendre ce qu'est XWindow pour pouvoir le configurer et l'utiliser. Son architecture se distingue en effet fortement de celle des environnements graphiques des systèmes classiques comme Windows, OS/2 ou Macintosh, et ces différences se traduisent dans la manière de l'utiliser.

La principale différence entre XWindow et les autres environnement graphiques est qu'il s'agit d'un environnement graphique distribué sur un réseau. La notion de base de XWindow est que l'application qui effectue le traitement ne réalise pas elle-même la gestion de l'environnement graphique. Comme on l'a déjà vu, cette tâche est prise en charge par le serveur X, qui est un processus indépendant. L'application est donc cliente du serveur X, qui lui fournit les services graphiques dont elle a besoin. Cette séparation a plusieurs conséquences :

• premièrement, l'environnement graphique est isolé des fautes des applications qui l'utilisent. Ainsi, ce n'est pas parce qu'une application a planté en plein écran qu'on ne peut pas réduire sa fenêtre et accéder à nouveau au bureau sous-jacent. Inversement, une application est isolée des erreurs potentielles du serveur X, et peut poursuivre son traitement même si celui-ci s'est terminé. Par exemple, un processus de gravage de CD peut terminer le CD en cours même s'il a perdu son interface graphique ;

• deuxièmement, les clients doivent établir une connexion avec le serveur. Cette connexion est réalisée par l'intermédiaire du réseau. Cela implique naturellement que les mécanismes de sécurité liés au réseau sont applicables pour toutes les applications désirant se connecter au serveur X. XWindow fournit par ailleurs des mécanismes de sécurité complémentaires, et les ressources graphiques ne peuvent être utilisées que par les processus qui y sont autorisées ;

• enfin, comme le client et le serveur X sont deux processus distincts et qu'ils communiquent par l'intermédiaire d'une connexion réseau, rien n'interdit de lancer le client et le serveur X sur deux machines distinctes. Ainsi, tout processus déporté peut afficher ses données en local (et inversement).

Chaque client doit donc se connecter au serveur X avec lequel il désire travailler. En pratique, il n'existe souvent qu'un seul serveur X sur une machine, mais cela n'est pas une obligation. Par exemple, une même machine peut disposer de deux cartes graphiques et de deux écrans, et faire tourner deux serveurs X distincts. Une autre possibilité est d'utiliser les deux écrans avec un seul serveur X pour faire un écran virtuel beaucoup plus grand. Enfin, il est tout à fait concevable de lancer plusieurs fois un même serveur X, même si l'on ne dispose que d'une seule carte graphique et d'un seul écran, afin de pouvoir utiliser plusieurs terminaux X virtuels. Comme on le voit, l'architecture client/serveur de XWindow lui apporte une très grande flexibilité.

Les serveurs X utilisent la notion de display pour gérer l'affichage. En fait, un display est constitué d'un clavier, d'une souris et d'un ou plusieurs écrans. Le display est donc l'extension de la notion de terminal pour XWindow. Notez bien qu'il est possible d'utiliser plusieurs écrans sur le même terminal X. Cependant, un serveur X ne peut prendre en charge qu'un seul terminal X sur une machine, et chaque display est géré par un serveur X qui lui est propre. Si l'on veut utiliser plusieurs terminaux X sur une même machine, il est nécessaire de lancer plusieurs serveurs X, à raison d'un par terminal.

Les clients qui désirent se connecter à un serveur X doivent donc indiquer le display avec lequel ils désirent travailler. Le système XWindow se chargera d'établir la connexion avec le serveur X en charge de ce display. Les displays sont spécifiés avec la syntaxe suivante :

machine:display

Comme on le voit, la présence du champ machine confirme que XWindow est bien un système graphique réseau. Il peut contenir directement le nom de la machine ou son adresse IP. Si ce champ est absent, le serveur contacté sera l'un des serveurs X de la machine locale, avec un protocole de communication optimisé. Le champ display quant à lui est un numéro permettant d'identifier le display de la machine en question qui doit être utilisé. C'est ce champ qui déterminera le serveur X qui sera utilisé, dans le cas où plusieurs serveurs X fonctionnent sur la même machine.

Un display pouvant avoir plusieurs écrans, il est possible de spécifier l'écran sur lequel l'affichage doit être réalisé. Pour cela, il suffit de suffixer le nom du display par un point suivi du numéro de l'écran :

machine:display.écran

Une fois la connexion établie, les programmes clients continuent d'indiquer à XWindow le display qui doit être utilisé pour chaque opération graphique à effectuer. Il est donc possible pour un programme de répartir son affichage sur plusieurs écrans, voire de communiquer avec plusieurs serveurs X et donc de gérer plusieurs displays simultanément, éventuellement sur des machines différentes. Ce genre de programme est cependant assez rare, et ne se trouve en pratique que dans le monde de la conception assistée par ordinateur, la visualisation d'images médicales et l'architecture. Les programmes classiques se contentent d'un seul display et effectuent toutes leurs opérations sur un même écran. En revanche, il est possible de configurer les serveurs X pour utiliser automatiquement plusieurs écrans pour un même display, afin de réaliser un écran virtuel gigantesque.

Le display utilisé pour un programme doit donc souvent être fixé par un paramètre de sa ligne de commande. L'option utilisée est -display, avec la syntaxe suivante :

programme -display nom

xterm -display :0

Vous pouvez cependant vous passer de l'option -display, à condition de définir la variable d'environnement DISPLAY pour fixer le display par défaut. Vous pouvez fixer la valeur de cette variable à l'aide d'une commande telle que celle-ci :

export DISPLAY=:0.0

En revanche, vous serez obligé de préciser le display à utiliser lorsque vous lancerez une application à distance en voulant avoir l'affichage en local. Bien entendu, vous devrez au préalable donner les droits à l'utilisateur distant sur votre display local, faute de quoi les mécanismes de sécurité de XWindow lui interdiront de se connecter (message d'erreur « Can't open display »). Nous verrons plus loin la manière dont XWindow gère la sécurité.