Chapitre 10. Installation de XWindow
- Table des matières
- 10.1. Généralités sur XWindow
- 10.2. Configuration de XFree86
- 10.3. Utilisation du pilote frame buffer du noyau
- 10.4. Configuration des terminaux X
- 10.5. Paramétrage des applications et ressources X
- 10.6. Gestion de la sécurité sous XWindow
- 10.7. Gestion des polices de caractères
- 10.8. Problèmes classiques rencontrés
L'installation de XWindow a été pendant longtemps une tâche ardue et risquée. À présent, il est possible d'installer cet environnement relativement facilement, et en prenant beaucoup moins de risques que par le passé. En fait, les seules difficultés dans l'installation de XWindow résident en deux points stratégiques :
il faut impérativement connaître les caractéristiques de son matériel (carte graphique et surtout moniteur) ;
il faut disposer d'un pilote adapté à sa carte graphique pour le serveur X.
Le premier point n'est pas réellement trop difficile à résoudre, puisqu'il suffit souvent de regarder les fiches techniques du matériel installé. Bien entendu, cela suppose de les avoir conservées. Si ce n'est pas le cas, il faut espérer que les programmes d'installation connaissent la marque et le modèle du matériel. Il reste toujours la possibilité de demander des renseignements à des personnes qui ont également ce type de matériel (c'est là qu'Internet peut être utile). Les informations les plus importantes sont les plages de fréquences horizontales et verticales du moniteur, ainsi que les durées des signaux de synchronisation horizontale et verticale. Sans ces informations, vous ne parviendrez pas à installer XWindow. Rassurez-vous cependant, les programmes de configuration de XWindow connaissent la plupart des moniteurs à présent, ce qui fait qu'ils sont capables d'écrire les fichiers de configuration correctement sans que vous ayez à spécifier les paramètres du moniteur.
Le deuxième point en revanche est plus délicat. Bon nombre de fabricants de matériel tiennent secrètes les informations techniques permettant de programmer un pilote, parce qu'ils considèrent que ce sont des informations stratégiques. Il est évident que dans ce cas, aucun pilote libre ne peut être écrit. Depuis quelques temps, ce problème ne se pose plus réellement en ce qui concerne l'affichage 2D, car le champ de bataille des constructeurs de cartes graphiques s'est déplacé vers le monde de la 3D. Dans le pire des cas, la carte graphique ne sera reconnue que par le pilote générique VESA, et l'affichage se fera correctement mais avec des performances bien en deçà de ce qu'elles auraient été si un pilote approprié avait existé. Il est donc recommandé de se renseigner dans les groupes de discussion sur Internet avant d'acheter une carte graphique, ou d'acheter une bonne carte graphique mais un peu obsolète. Il faut savoir que de toutes façons, les dernières fonctionnalités sont toujours intégrées avec un train de retard sous Linux, car il faut au moins le temps d'écrire les pilotes et de les tester. Dans peu de temps, Linux sera sans aucun doute reconnu comme un système à part entière par les fabricants, et il est probable qu'ils fourniront des pilotes comme pour les autres systèmes. En attendant, assurez-vous bien que ce que vous achetez fonctionne sous Linux.
Il n'y a que trois solutions si aucun serveur X adapté à votre matériel n'est fourni avec votre distribution :
soit le fabricant de la carte graphique fournit un serveur X pour Linux (ce qui est très rare, mais commence à arriver) ;
soit on utilise le pilote VESA fourni avec XFree86, qui fonctionne avec toutes les cartes graphiques compatibles avec le standard VESA
soit une société tierce vend un serveur X pour ce type de matériel (ce qui est moins rare, mais a l'immense inconvénient qu'il faut acheter ses pilotes) ;
Ce chapitre décrit la manière de procéder pour installer et configurer XFree86, une implémentation libre de XWindow. Il indique également comment installer le serveur X pour le pilote de frame buffer du noyau. L'installation des polices Truetype, qui sont si chères aux utilisateurs de Windows et des Macintosh, est également traitée. En revanche, il ne décrira pas comment configurer les gestionnaires de fenêtres ni les gestionnaires de bureau, car ces opérations sont spécifiques à celui que vous choisirez d'une part, et spécifiques à vos desiderata d'autre part. Pour cela, vous devrez commencer à vous débrouiller tout seul, à lire les pages de manuel et à poser les questions qu'il faut aux personnes qu'il faut. Mais ne paniquez pas, si vous êtes arrivé jusqu'ici, c'est que vous commencez à savoir vous débrouiller. Vous ne devriez plus trop avoir de problèmes pour tirer de Linux tout ce dont vous avez besoin...
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.écranoù le champ écran spécifie le numéro de l'écran de ce display sur lequel l'affichage doit avoir lieu. Ce champ sera rarement utilisé en pratique, car il est assez rare de disposer de plusieurs écrans. Il peut donc être omis, la valeur par défaut utilisée est dans ce cas 0 (pour le premier et unique écran du display).
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 nomoù programme est le programme à exécuter, et nom est le nom du display tel qu'il a été décrit ci-dessus. Par exemple, la commande suivante : permet de lancer le programme xterm et de réaliser l'affichage sur le display :0 (sur l'écran par défaut) de la machine locale.
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 :
(si vous utilisez bash). Dans cet exemple, le serveur X à utiliser se trouve sur la machine locale, le display porte le numéro 0, et l'écran à utiliser est le numéro 0. En général, cette variable d'environnement est fixée à la valeur du display courant lorsqu'on est connecté sous XWindow. Par conséquent, vous pouvez lancer vos programmes sans avoir à vous préoccuper du display qu'ils doivent utiliser.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é.