Guide d'installation et de configuration de Linux

X. Installation de XWindow▲

Ce chapitre décrit la manière de procéder pour installer et configurer X.org, une implémentation libre de XWindow dérivée du projet XFree86. 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…

X-A. 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 environnements 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és ;
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 :

Sélectionnez

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 :

Sélectionnez

machine:display.écran

où 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).

Image non disponible — Notion de 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 :

Sélectionnez

programme -display nom

où 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 :

Sélectionnez

xterm -display :0

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 :

Sélectionnez

export DISPLAY=:0.0

(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é.

X-B. Installation de X.org▲

Il existe actuellement deux implémentations libres de XWindow : l'implémentation historique, XFree86, et une branche de XFree86 créée récemment pour des raisons politiques, X.org. Cette duplication est dûe au fait que beaucoup de développeurs n'ont pas eu le sentiment que leurs requêtes étaient prises en compte par l'équipe de développement de XFree86, qui est restée très conservatrice pendant de longues années. Ces problèmes ont même provoqué des querelles intestines au sein de l'équipe de XFree86. N'ayant pu se mettre d'accord, les différentes parties ont décidé de développer leur propre version de XWindow séparément. À ces problèmes s'est ajouté un changement de licence du projet XFree86 qui, bien que restant libre, n'a pas été du goût de tout le monde. C'était en quelque sorte la goutte qui a fait déborder le vase.

J'ai pris le parti de décrire X.org dans ce document, bien que j'estime que l'on doive encore rendre crédit à l'équipe de XFree86. Je considère en effet que les reproches qui sont faits au projet XFree86 sont justifiés (lenteur du projet, intégration et mises à jour des composants annexes trop lentes, refus d'intégration des modifications nécessaires aux autres projets utilisant XFree86, organisation du projet monolithique et sans volonté de le rendre plus modulaire, entre autres problèmes). De plus, il semble que les principales distributions et constructeurs de matériel informatique aient décidé de suivre cette voie. Enfin, je considère que le changement de licence de XFree86 n'était pas nécessaire et relève de la tentative de putsch de la part de l'équipe de développement actuelle d'une part, et n'a été fait que pour des raisons politiques d'autre part. Il n'est pas certain que les deux projets subsistent à l'avenir, seul l'avenir dira qui avait raison.

Bien que développés par des équipes différentes, XFree86 et X.org sont basés sur les mêmes sources et sont donc totalement compatibles. Cela ne durera pas forcément, car X.org est appelé à évoluer différemment et plus vite que XFree86, mais à l'heure actuelle, les deux produits n'ont pas eu le temps de diverger suffisamment pour créer des incompatibilités. Les seules différentes se situent donc au niveau des noms des commandes et des fichiers de configuration, qui ont été renommés dans X.org pour bien se distinguer de XFree86. Par conséquent, si votre distribution utilise XFree86, vous n'aurez que très peu d'adaptations à faire pour lire ce chapitre.

L'installation de XWindow a été pendant longtemps une tâche ardue et risquée. À présent, il est possible d'installer et de configurer cet environnement relativement facilement, et en prenant beaucoup moins de risques que par le passé. La plupart des distributions installent XWindow et le configurent automatiquement, ce qui fait que vous n'aurez généralement rien à faire. Les informations de ce chapitre ne vous seront donc utiles que pour comprendre comment effectuer des modifications dans la configuration du système.

En fait, les seules difficultés que vous pourrez rencontrer résident dans le choix du pilote utilisé par le serveur X pour prendre en charge votre carte graphique et dans sa configuration. L'essentiel de ces opérations réside donc dans ces deux points stratégiques :

il faut disposer d'un pilote adapté à sa carte graphique pour le serveur X ;
si l'écran utilisé est relativement ancien (écran cathodique non compatible avec le protocole DDC), il vous faudra éventuellement connaître les caractéristiques de votre matériel (essentiellement les fréquences de balayage horizontales et verticales supportées par votre moniteur).

Le premier point est quasiment assuré de nos jours, car la plupart des cartes graphiques vendues sur le marché de nos jours sont des cartes de marque Intel (surtout pour les puces graphiques intégrées au chipset), nVidia et ATI. Des pilotes sont disponibles pour la plupart des modèles de ces fabricants.

En fait, vous devrez essentiellement choisir entre les pilotes libres fournis avec X.org, généralement plus stables, mais ne supportant pas forcément les dernières cartes graphiques ou la totalité des fonctions 3D, et les pilotes propriétaires fournis par le fabricant, qui ne supportent souvent pas les anciennes cartes ou qui ne sont pas compatibles avec tous les noyaux, qui sont parfois relativement instables (surtout les pilotes AMD et, dans une moindre mesure, les pilotes nVidia des « anciennes » cartes), mais qui donnent accès à l'ensemble des fonctions 3D.

Note : En fait, seul Intel joue le jeu des pilotes libres, bien qu'ATI semble à nouveau considérer la question depuis son rachat par AMD. NVidia quant à lui fournit des pilotes propriétaires de très bonne qualité et la prise en charge des cartes NVidia sous Linux est excellente. Toutefois, cette société s'est toujours opposée à ce qu'un pilote libre existe (à tel point qu'elle a même fait pression pour que le code source du pilote 2D de X.org soit crypté). À vous de faire votre choix en fonction de vos contraintes financières, matérielles et morales…

Si d'aventure vous ne disposez d'aucun serveur X adapté à votre matériel (matériel trop récent pour lequel le constructeur lui-même n'a pas encore fourni le pilote), vous pourrez vous rabattre sur le pilote VESA, qui fonctionne avec toutes les cartes graphiques compatibles avec le standard VESA. Toutefois, ce pilote ne vous fera bénéficier d'aucune accélération graphique, même 2D.

Pour ce qui est du deuxième point, l'avènement des écrans plats a simplifié considérablement la donne : non seulement ces écrans ne supportent plus qu'une seule résolution, mais la notion de balayage n'a plus de sens non plus. Ces écrans fournissent également les informations nécessaires aux pilotes de cartes graphiques permettant de déterminer les modes graphiques supportés. Toutefois, si votre écran est un vieil écran cathodique, vous aurez peut-être à connaître ses caractéristiques techniques. Pour cela, il suffit souvent de regarder la fiche technique de l'écran. Bien entendu, cela suppose de l'avoir conservée. 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 peut-être 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.

X-C. Configuration de X.org▲

La configuration de X.org commence avant tout par l'installation du serveur X. Un même serveur X peut prendre en charge plusieurs cartes graphiques sur une même machine, pourvu qu'il dispose des pilotes adéquats. Inversement, il est possible de lancer plusieurs serveurs X, chacun utilisant sa propre carte graphique, ou partageant la même carte si la machine n'a qu'un seul terminal X.

X.org fournit un unique serveur X, qui prend en charge tous les types de cartes graphiques à l'aide de pilotes spécifiques. Dans une installation normale, ces pilotes sont fournis sous forme de modules de ce serveur. Les pilotes peuvent ainsi être chargés dynamiquement par le serveur X, selon la configuration du système. Cette architecture permet à un même serveur X de charger plusieurs pilotes pour plusieurs cartes graphiques, afin de gérer les configurations disposant de plusieurs écrans connectés à des cartes graphiques de différents types. Il est donc nécessaire que les modules prenant en charge vos cartes graphiques soient installés, ce qui est normalement toujours le cas.

Par convention, le nom du serveur X est toujours X. Comme le nom du fichier programme du serveur X de X.org est Xorg (on s'en serait douté…), il doit exister un lien symbolique /usr/bin/X qui pointe vers le fichier /usr/bin/Xorg. Ce lien est, encore une fois, normalement toujours présent sur les systèmes correctement configurés.

Une fois XWindow installé, la suite de la configuration de X.org se fait uniquement dans le fichier de configuration xorg.conf. Ce fichier est classiquement stocké dans le répertoire /etc/X11/. Normalement, vous ne devez pas créer ce fichier vous-même. Votre distribution doit au moins vous en fournir un par défaut et, souvent, elle dispose d'un outil de configuration de X.org convivial qui fera quasiment tout le travail pour vous. Ce genre d'outil est de plus capable de configurer X.org pour les pilotes spécifiques fournis avec les distributions (il n'est pas rare que les sociétés éditrices de distributions développent des serveurs X pour les nouvelles cartes graphiques). Lisez donc votre documentation pour plus de détails à ce sujet.

Vous pouvez également utiliser les programmes de configuration fournis avec X.org, qui vous permettront de générer ce fichier. Il existe trois possibilités pour générer un fichier de configuration xorg.conf. La première méthode est de demander directement au serveur X de détecter le matériel présent sur votre machine et de générer le fichier xorg.conf correspondant. La deuxième méthode, qui est aussi la plus sûre, est d'utiliser le programme xorgconfig. Il s'agit d'un outil fonctionnant en mode texte, qui est effroyablement peu pratique à utiliser. Enfin, un autre outil, beaucoup plus convivial, est en cours de développement. Il s'agit de xorgcfg. Cet outil permet de générer et de modifier les fichiers xorg.conf de manière conviviale, soit en mode texte avec des menus, soit en mode graphique. Lorsque cet outil sera terminé, la configuration de X.org sera beaucoup plus aisée. Encore une fois, je ne saurai que vous recommander d'utiliser l'outil de configuration fourni avec votre distribution.

X-C-1. Génération automatique du fichier xorg.conf▲

Le serveur X de X.org est capable de détecter le matériel installé sur une machine et de générer un fichier de configuration xorg.conf adapté à ce matériel. Pour cela, il suffit de le lancer avec l'option -configure sous le compte root, comme dans l'exemple suivant :

Sélectionnez

Xorg -configure

À l'issue de cette commande, le serveur X écrira un fichier xorg.conf.new dans le répertoire personnel de l'utilisateur root.

Cependant, le fichier de configuration ainsi généré n'utilisera que les options de configuration les plus sûres et devra souvent être révisé complètement. En pratique, seuls les paramètres de la carte graphique et de la souris seront correctement détectés. Il ne faut donc utiliser cette fonctionnalité que dans le but d'obtenir un squelette de fichier xorg.conf, que l'on personnalisera ensuite. Ce fichier pourra être copié dans le répertoire /etc/X11/ sous le nom xorg.conf une fois qu'il aura été corrigé.

X-C-2. Utilisation de xorgconfig▲

Comme il l'a été indiqué plus haut, xorgconfig est un programme fonctionnant en mode texte exclusivement. Son principe de fonctionnement est très simple : il pose une série de questions sur votre matériel, puis il génère un fichier xorg.conf générique pour votre matériel. Vous pourrez ensuite partir de ce modèle pour personnaliser votre configuration et pour préciser les paramètres que xorgconfig ne prend pas en charge.

Le principal problème de xorgconfig est qu'il ne laisse pas droit à l'erreur. La moindre faute de frappe ou la moindre hésitation est prise comme une réponse valide, et il est impossible de revenir en arrière. Cela est d'autant plus énervant que dans ce cas, il ne reste plus qu'une solution, qui est de tout recommencer à partir du début. Après trois ou quatre erreurs, on finit par faire extrêmement attention à ce que l'on tape.

Lorsqu'on lance xorgconfig, il commence par afficher un message indiquant qu'il va créer un nouveau fichier de configuration xorg.conf que l'on pourra utiliser par la suite comme point de départ pour paramétrer son système XWindow. Il faut valider pour passer ce message et commencer la configuration proprement dite.

La première question que xorgconfig pose est le type de la souris que vous voulez utiliser. Il existe un grand nombre de types de souris sur le marché, cependant seuls deux types sont réellement courants.

Initialement, les souris se connectaient sur le port série des ordinateurs. Ces souris, dites souris sérielles, étaient relativement répandues et sont généralement référencées sous le terme de « compatible Microsoft ». Il faut donc utiliser l'option « Microsoft compatible (2-button protocol) » pour ces souris. Notez que certaines souris sérielles utilisent un protocole différent pour gérer un troisième bouton. Si vous disposez d'une telle souris, il faut choisir l'option « Mouse Systems (3-button protocol) ».

Plus récemment, le port PS/2 est apparu pour les claviers et les souris. Ce port permet de gérer directement la plupart des souris actuelles, et il est probable que votre souris soit une souris PS/2. L'option à utiliser est cette fois l'option « PS/2 Mouse ». Il faut surtout ne pas confondre les souris PS/2 avec les souris bus (que l'on peut utiliser avec l'option « Bus Mouse »), qui sont des souris relativement peu répandues et qui utilisaient des bus spéciaux. Les autres options sont réservées à des souris peu répandues. Si vous en utilisez une, vous devez choisir l'option correspondante.

Notez que les souris à molette connectées sur le port PS/2 utilisent un protocole de communication légèrement différent de celui que les autres souris PS/2 utilisent. Malheureusement, xorgconfig ne propose pas d'option pour ces souris, et une intervention manuelle dans le fichier de configuration xorg.conf est nécessaire pour les configurer. La manière de procéder sera détaillée dans la Section 10.3.4.

La question suivante demande si vous désirez activer la fonctionnalité d'émulation d'un troisième bouton pour les souris à deux boutons. Cette émulation permet d'utiliser les nombreux programmes pour XWindow qui nécessitent d'utiliser une souris à trois boutons. Le clic sur le troisième bouton est alors simulé en appuyant sur les deux boutons de la souris simultanément. Il est très vivement recommandé de répondre par 'y' à cette question si votre souris ne dispose que de deux boutons. En revanche, si elle dispose de plus de trois boutons, ou si elle dispose d'une roulette, il faut répondre par la négative.

xorgconfig demande ensuite le port sur lequel votre souris est connectée. Ce port est généralement le port /dev/ttyS0 pour les souris sérielles et /dev/psaux pour les souris PS/2. Les distributions créent souvent un lien symbolique /dev/mouse sur le port effectivement utilisé par la souris, si bien que la réponse par défaut utilise ce port. C'est la réponse recommandée, validez donc pour passer à la question suivante.

Vient ensuite la sélection du type de clavier. Encore une fois, un certain nombre de modèles de claviers ont été vendus sur le marché. Cependant, seuls quelques-uns sont réellement répandus. En France, on trouve essentiellement les claviers internationaux 102 touches et 105 touches, auxquels correspondent les réponses « Generic 102-key (Intl) PC » et « Generic 105-key (Intl) PC ». Si vous utilisez un clavier Microsoft Natural Keyboard, choisissez l'option « Microsoft Natural ».

Vous devrez ensuite indiquer la disposition de ce clavier. Il faut évidemment choisir l'option « French ». xorgconfig demande alors de saisir un nom de variante pour le clavier choisi. Comme le clavier français n'est décliné que sous une seule variante, vous pouvez simplement valider pour passer à la suite de la configuration du clavier.

xorgconfig vous propose alors de modifier des paramètres additionnels du clavier (emplacement des touches modificatrices telles que les touches de majuscule, de contrôle et de jeu de caractères alternatif, état des diodes, etc.). En général, cela n'est pas nécessaire et vous pouvez répondre 'n' à cette question.

La partie difficile vient ensuite. xorgconfig vous le signale avec un message indiquant que les informations de synchronisation horizontale et verticale sont extrêmement importantes pour configurer correctement les modes vidéo. La signification de ces valeurs vous sera décrite plus loin en détail, pour l'instant, contentez-vous de récupérer le manuel de votre moniteur et recherchez ses caractéristiques précises. Validez ensuite pour passer à la question suivante.

xorgconfig vous demande alors la plage de fréquences horizontales que votre moniteur est en mesure d'accepter. Il propose un certain nombre de choix standards, qui correspondent aux différents types de moniteurs existant sur le marché. Cependant, ces valeurs sont les plus mauvaises, car il est fort probable que votre moniteur sache faire mieux que ce que les standards imposent. Vous devez donc soit accepter une des plages de valeurs proposées, soit saisir la plage correspondant exactement à votre moniteur à l'aide de l'option « Enter your own horizontal sync range ». Si vous choisissez cette dernière option, vous devrez ensuite saisir la plage de valeurs des fréquences horizontales de votre moniteur. Ne les inventez pas, cela ne marchera pas. Saisissez les vraies valeurs.

La même question est alors posée pour la plage de fréquences verticales. Encore une fois, vous pouvez choisir l'une des plages proposées selon le type de votre moniteur, ou saisir vous-même la plage de fréquences citée dans ses caractéristiques techniques à l'aide de l'option « Enter your own vertical sync range ». À l'issue de cette question, xorgconfig vous demande de saisir le nom du moniteur que vous venez ainsi de configurer. Ce nom est arbitraire, il ne sert que pour l'identifier de manière lisible par la suite. Entrez, par exemple, le nom du modèle de l'écran dont vous disposez.

La question suivante vous demande simplement si vous désirez choisir votre carte graphique dans la liste des cartes graphiques supportées par X.org. Il est recommandé de répondre par l'affirmative en tapant 'y'. xorgconfig affiche alors la liste des cartes gérées, qui est assez longue. En fait, elle se présente sur plusieurs pages, et il faut appuyer sur la touche Entrée pour passer d'une page à la suivante. Si vous avez passé une page de trop, vous êtes bon pour passer toutes les pages pour revenir à la première, avant d'aller sur la page contenant votre carte graphique. Lorsque vous aurez trouvé votre carte, choisissez l'option correspondante et validez.

Si votre carte n'est pas présente dans la liste, cela ne signifie pas qu'elle n'est pas supportée par X.org. En effet, chaque pilote est capable de prendre en charge un type de puce électronique, et il arrive que plusieurs cartes graphiques soient basées sur une électronique provenant d'un même fabricant. C'est la raison pour laquelle les pilotes de X.org portent généralement le nom des puces utilisées par les cartes. Par conséquent, si vous ne trouvez pas votre carte dans la liste, vous pouvez essayer de spécifier le pilote correspondant à l'électronique de votre carte. Dans le pire des cas, vous pourrez quasiment toujours utiliser le pilote générique VESA, qui permet de piloter toutes les cartes graphiques compatibles avec les standards VESA 2.0. Cependant, vous ne bénéficierez d'aucune accélération matérielle avec ce pilote.

Les questions qui suivent dépendent fortement de la carte sélectionnée. En effet, chaque carte peut avoir besoin d'un certain nombre de paramètres complémentaires pour fonctionner. Encore une fois, ces paramètres sont, normalement, indiqués dans le mode d'emploi de votre carte graphique ou, au pire, sur les composants de la carte eux-mêmes. Une des questions courantes concerne la quantité de mémoire vidéo dont cette carte dispose. Pour cette question, les choix les plus courants sont proposés, mais vous pouvez également spécifier vous-même cette quantité à l'aide de l'option « Other ». L'unité est ici le kilo-octet, pensez donc bien à multiplier par 1024 le nombre de mégaoctets de mémoire vidéo de votre carte graphique avant de saisir la valeur. Lorque la configuration de la carte graphique sera terminée, xorgconfig vous demandera de saisir le nom de cette carte. Encore une fois, ce nom est arbitraire, mais vous devriez saisir un nom cohérent avec votre modèle.

xorgconfig vous propose alors de modifier l'ordre d'utilisation des modes graphiques pour chaque profondeur de couleur. Cet ordre doit être spécifié en donnant les numéros des différents modes, les uns après les autres, et en ne les séparant pas par des espaces. Par exemple, le nombre 432 sélectionnera les modes 4, 3 et 2, soit les modes 1024x768, 800x600 et 640x480. Notez que l'ordre des numéros est important, c'est l'ordre dans lequel ces modes seront choisis lorsqu'on basculera de l'un à l'autre. Lorsque vous aurez saisi les modes graphiques à utiliser et leur ordre d'apparition, xorgconfig vous proposera d'utiliser un écran virtuel de taille supérieure à la résolution physique du plus grand des modes graphiques choisis. Cela signifie que la résolution de l'affichage sera supérieure à celle de votre écran, et que XWindow fera défiler automatiquement l'image affichée lorsque la souris sortira de la portion d'image visible. Il est en général conseillé de répondre par la négative à cette question, car cela peut être facilement déroutant. Cependant, c'est une affaire de goût, et vous êtes libre d'accepter ce comportement. Notez que, quelle que soit la réponse que vous donnerez, XWindow utilisera comme résolution logique la résolution du plus grand mode que vous avez sélectionné. Par conséquent, ce mécanisme de défilement sera encore utilisé pour les modes graphiques de résolution inférieure, avec comme taille d'écran virtuel la taille du mode ayant la résolution la plus grande. Lorsque vous aurez configuré tous vos modes graphiques, vous pourrez passer à la suite en choisissant l'option « The modes are OK, continue. ».

xorgconfig vous demande alors le nombre de couleurs à utiliser par défaut lorsque vous démarrez en mode graphique. Choisissez bien, car il ne sera pas possible de changer cette valeur une fois que l'environnement graphique sera lancé. Vous pourrez bien entendu la modifier manuellement, mais il vous faudra relancer le serveur X après cela. La plupart des cartes graphiques modernes supportent les modes graphiques à 16 millions de couleurs, la réponse recommandée est donc « 24 bits (16 millions colors) ».

Enfin, la dernière question est tout simplement si vous désirez enregistrer le fichier xorg.conf correspondant aux options que vous avez choisies. Il faut bien entendu répondre par 'y', ou sinon vous devriez vous demander pourquoi vous êtes en train de lire ceci…

Le fichier xorg.conf généré est généralement fonctionnel, mais parfaitement améliorable. Le format de ce fichier sera décrit en détail dans la Section 10.3.4. Si vous l'ouvrez, vous constaterez que xorgconfig a ajouté un nombre impressionnant de commentaires pour vous aider dans vos expérimentations. Bien entendu, vous trouverez également des informations complémentaires dans la page de manuel xorg.conf.

X-C-3. Utilisation de xorgcfg▲

La manière la plus agréable d'effectuer la configuration de X.org est sans nul doute d'utiliser l'utilitaire xorgcfg. Ce programme permet aussi bien de créer un fichier de configuration xorg.conf initial que de modifier une configuration existante de manière graphique. Il dispose également d'un mode texte, qui reprend les mêmes questions que xorgconfig, mais d'une manière plus conviviale, à l'aide d'un système de menus.

X-C-3-a. Configuration en mode graphique▲

Lorsqu'on lance xorgcfg, celui-ci commence par regarder si la variable d'environnement DISPLAY est définie ou non. Si elle est définie, il tente de se connecter au serveur X gérant ce display afin de permettre l'édition du fichier de configuration xorg.conf du système. Notez qu'il ne permet pas de modifier le fichier xorg.conf utilisé par le serveur X auquel il se connecte si celui-ci utilise un autre fichier que le fichier du système : le serveur X n'est utilisé par xorgcfg que pour son affichage.

Si, en revanche, la variable d'environnement DISPLAY n'est pas définie, xorgcfg considère que XWindow n'est pas installé sur la machine locale et appelle le serveur X avec l'option -configure afin de générer un nouveau fichier xorg.conf. Il lance ensuite le serveur X détecté et utilise ce serveur pour permettre la modification du fichier xorg.conf ainsi créé.

À son démarrage, il vérifie que la souris est correctement configurée. Si tel n'est pas le cas, il propose d'utiliser les touches du curseur du pavé numérique pour déplacer le pointeur de la souris, ainsi que les touches /, * et - respectivement pour le premier, le deuxième et le troisième bouton de la souris. Je déconseille fortement d'essayer d'effectuer la configuration dans ces conditions, car ce n'est réellement pas utilisable. Dans ce cas de figure, on cherchera plutôt à utiliser l'interface en mode texte de xorgcfg, que nous présenterons dans la section suivante.

L'interface de xorgcfg en mode graphique est très simple. La partie supérieure de la fenêtre comprend un menu avec deux entrées. La première entrée permet de choisir les différentes parties intervenant dans la configuration. La deuxième entrée (intitulée « Expert Mode ») donne accès quant à elle à un mode de paramétrage permettant d'éditer directement les propriétés du fichier xorg.conf. Ce mode de fonctionnement est réservé aux utilisateurs avertis et ne sera pas décrit ici.

La première entrée de menu comprend plusieurs options. L'option « Configure Layout » permet d'effectuer la configuration générale du display. L'option « Configure Screen » permet de configurer la disposition des différents écrans d'un même display les uns par rapport aux autres. Elle n'est réellement utile que dans le cas des configurations à plusieurs écrans. L'option « Configure Modeline » donne la possibilité de configurer les différents modes graphiques de chaque configuration. Enfin, l'option « Configure AccessX » permet de spécifier les options des différents périphériques d'entrée. Ces deux options de menus sont réservées aux utilisateurs expérimentés et ne seront pas décrites dans ce document.

L'essentiel de la configuration se fait dans l'écran affiché lorsque l'option « Configure Layout » est choisie. Cet écran est constitué d'une barre d'icônes permettant d'ajouter les différents périphériques à la configuration courante : souris, claviers, cartes graphiques et moniteurs. Il n'est possible d'éditer qu'une seule configuration à la fois, la configuration courante peut être sélectionnée à l'aide du bouton situé dans la partie inférieure gauche de la fenêtre. Le corps de la fenêtre elle-même contient une représentation de cette configuration, avec les différents périphériques utilisés et les relations qui existent entre eux.

En cliquant avec le bouton droit de la souris sur ces éléments, vous pouvez faire apparaître un menu contextuel concernant cet élément. Ce menu peut contenir l'option « configure », qui donne accès à une boîte de dialogue permettant d'éditer les propriétés de l'élément, l'option « option », qui permet d'ajouter des options générales à cet élément, les options « enable » et « disable », qui permettent d'activer ou de désactiver l'élément en question dans la configuration, et l'option « remove », dont le but est de supprimer l'élément concerné.

Une configuration typique comprend au moins une souris, un clavier, une carte graphique et un moniteur. Il est recommandé d'ajouter les éléments de la configuration dans cet ordre, afin d'éviter d'avoir à revenir plusieurs fois sur certains de ces éléments.

La boîte de dialogue ouverte par l'option « configure » sur une souris comprend un champ contenant l'identificateur de cette souris, la liste des fichiers spéciaux de périphériques pour la sélection du fichier spécial de périphérique auquel la souris est connectée, la liste des protocoles gérés par X.org et un bouton permettant d'activer l'émulation du troisième bouton pour les souris à deux boutons. Généralement, les souris sont connectées soit sur le port série (fichier spécial de périphérique /dev/ttyS0 ou /dev/ttyS1), soit sur le port PS/2 (fichier spécial de périphérique /dev/psaux). Les principaux protocoles gérés par X.org sont les suivants :

Microsoft

C'est le protocole utilisé par la plupart des souris connectées sur le port série. Ce type de souris est de plus en plus rare actuellement, ne choisissez cette option que si vous disposez de ce type de souris ;

IntelliMouse

C'est le protocole utilisé par les souris à molette connectées sur le port série. N'utilisez pas ce protocole pour les souris à molette connectées sur le port PS/2, la souris ne fonctionnerait pas.

PS/2

C'est le protocole qui convient pour la majorité des souris connectées sur un port PS/2. Notez toutefois que ce n'est pas le cas des souris à molette Logitech et Microsoft ;

IMPS/2

C'est le protocole des souris à molette connectées sur port PS/2. Malheureusement, ce protocole n'est pas proposé par xorgcfg. Il est donc impossible de configurer une souris de ce type avec cet utilitaire, sauf à passer dans le mode expert. La configuration à utiliser pour ce type de souris sera décrite dans la Section 10.3.4.

Lorsque vous aurez configuré votre souris, vous pourrez utiliser le bouton « Apply changes » pour prendre en compte les changements si vous avez modifié les paramètres de la souris courante. Dès lors, vous devriez avoir une souris fonctionnelle, et vous pouvez l'activer avec l'option « enable » du menu contextuel. Lorsque la souris est activée, un lien apparaît entre l'unité centrale de l'ordinateur et cette souris dans la fenêtre de xorgcfg.

La boîte de dialogue ouverte par l'option « configure » du menu contextuel des claviers comprend, comme la boîte de dialogue des propriétés des souris, un champ permettant de saisir le nom de ce clavier dans la configuration. Vous pouvez également choisir le modèle de clavier et sa disposition en fonction de sa langue. Pour les claviers français, le modèle à utiliser est généralement celui des claviers internationaux 102 ou 105 touches, et la disposition à utiliser est la disposition « French ». Lorsque vous aurez configuré le clavier correctement, vous pourrez appliquer les changements avec le bouton « Apply changes ». Vous pourrez également activer le clavier dans la configuration courante à l'aide de l'option « enable » du menu contextuel du clavier. Un lien entre ce clavier et l'unité centrale doit alors apparaître dans la fenêtre principale de xorgcfg.

La boîte de configuration des cartes graphiques contient le champ habituel pour donner un nom à la carte et la liste des cartes graphiques reconnues automatiquement par X.org. Si votre carte ne se trouve pas dans cette liste, vous devrez choisir le pilote à utiliser. En général, les pilotes portent le nom de la puce électronique sur laquelle la carte graphique est basée. Si aucun pilote n'est adapté pour votre carte, vous pourrez malgré tout utiliser un des pilotes génériques vga ou vesa. Enfin, dans le cas où plusieurs cartes graphiques sont installées dans l'ordinateur, vous devrez spécifier l'adresse de la carte sur le bus PCI/AGP. N'oubliez pas d'activer la carte graphique à l'aide de l'option « enable » du menu contextuel lorsque vous aurez fini la configuration.

La boîte de dialogue des moniteurs permet de spécifier un nom pour le moniteur ainsi que ses plages de fréquences horizontales et verticales. Vous pouvez aussi sélectionner la carte graphique à laquelle ce moniteur est connecté. La liste ne propose que les cartes graphiques que vous avez configurées précédemment. Les moniteurs n'ont pas besoin d'être activés, car ils sont liés aux cartes graphiques.

Une fois la configuration générale définie, vous pouvez, si elle contient plusieurs écrans, spécifier la disposition relative de ces écrans à l'aide de l'option « Configure Screen » du menu principal de xorgcfg. Cette option affiche les différents écrans dans la fenêtre de xorgcfg, et vous pouvez les faire glisser pour les disposer comme vous le désirez.

Enfin, l'option de menu principal « Configure Modeline » vous permettra de définir de nouveaux modes graphiques et de les ajuster. Cet écran fournit les mêmes fonctionnalités que l'utilitaire xvidtune, que l'on décrira en détail dans la Section 10.3.6. Cet écran ne sera donc pas traité plus en détail ici.

Lorsque vous quittez xorgcfg, il vous propose d'enregistrer le fichier de configuration /etc/X11/xorg.conf correspondant à la configuration que vous venez de définir. Vous pouvez spécifier un autre nom si vous le désirez, afin d'enregistrer ces paramètres dans un autre fichier. xorgcfg demande également si vous désirez sauvegarder la configuration du clavier, pour le cas où vous auriez modifié les paramètres des périphériques d'entrée.

X-C-3-b. Configuration en mode texte▲

xorgcfg permet également d'effectuer la configuration de X.org en mode texte, à l'aide d'une interface basée sur un système de menus. Bien que ce mode de fonctionnement soit en mode texte, il permet d'effectuer les mêmes tâches que xorgconfig d'une manière beaucoup plus conviviale.

Pour lancer xorgcfg en mode texte, il suffit simplement de lui passer l'option -textmode en ligne de commande :

Sélectionnez

xorgcfg -textmode

Lors de son démarrage, xorgcfg affiche un écran d'accueil que vous pouvez passer en validant l'option « OK ».

xorgcfg affiche ensuite son menu principal, qui comprend des entrées pour ajouter des souris, claviers, moniteurs et cartes graphiques. Ce menu contient également une entrée « Configure screen », qui permet d'associer les cartes graphiques aux moniteurs, et une entrée « Configure layout », qui permet de configurer le display en spécifiant le clavier, la souris et les différents écrans à utiliser.

Le menu de configuration de la souris permet d'ajouter, de supprimer et de modifier des souris. L'ajout d'une souris nécessite de saisir un identificateur pour la souris, le protocole que cette souris utilise et si le troisième bouton doit être simulé ou non. xorgcfg demande également le fichier spécial de périphérique à utiliser pour accéder à cette souris. Notez que xorgcfg ne permet pas de choisir le protocole IMPS/2 utilisé par les souris à molette connectées sur le port PS/2, ce type de souris ne peut donc pas être configuré avec cet outil.

De la même manière, le menu de configuration du clavier demande de saisir un identificateur lorsqu'on ajoute un nouveau clavier. Le type de clavier est également demandé, ainsi que sa disposition. Pour les claviers français, il faut utiliser les claviers internationaux 102 ou 105 touches.

La configuration des moniteurs permet de spécifier un identificateur pour le moniteur, ainsi que les plages de fréquences horizontales et verticales. La configuration des cartes graphiques quant à elle permet également de spécifier un identificateur pour la carte, et de choisir le type de carte dans la liste des cartes prises en charge par X.org. Si votre carte n'est pas listée, vous devrez choisir l'option « ** Unlisted card ** » et indiquer le pilote à utiliser pour cette carte. Ce pilote porte généralement le nom de la puce électronique sur laquelle cette carte est conçue, mais vous pouvez également utiliser les pilotes génériques vga et vesa pour les cartes graphiques compatibles avec ces standards. Enfin, xorgcfg vous propose de spécifier l'adresse de la carte sur le bus PCI/AGP, pour le cas où vous auriez plusieurs cartes installées sur la même machine.

Les identifiants donnés aux moniteurs et aux cartes sont utilisés dans le menu de configuration des écrans, qui demande quelle carte et quel moniteur sont utilisés pour chaque écran. La profondeur de couleur par défaut est également demandée, ainsi que la liste des modes graphiques gérés par cet écran. Notez que l'interface en mode texte de xorgcfg ne permet pas de définir de nouveaux modes graphiques, pour cela, il faut recourir à l'interface en mode graphique ou éditer manuellement le fichier de configuration xorg.conf.

Enfin, le menu de configuration général permet de définir, de modifier et de supprimer les displays. Chaque display doit contenir une référence à une souris, un clavier et un ou plusieurs écrans. Remarquez encore une fois que l'interface en mode texte de xorgcfg ne permet pas de préciser la disposition relative des écrans les uns par rapport aux autres. Pour cela, vous devrez utiliser l'interface en mode graphique ou éditer manuellement le fichier de configuration de X.org.

Lorsque vous aurez fini la configuration de X.org, vous pourrez l'enregistrer à l'aide du menu « Write xorg.conf and quit ». Ce menu vous demande le chemin complet sur le fichier de configuration à écrire. Vous pouvez spécifier un autre fichier que le fichier de configuration du système si vous désirez l'éditer et le modifier manuellement de manière indépendante.

X-C-4. Description du fichier xorg.conf▲

Les fichiers générés par les outils de configuration de X.org sont, comme nous l'avons déjà précisé, des fichiers devant servir de point de départ pour réaliser votre configuration. Normalement, ils permettent de démarrer le serveur X et de travailler dans de bonnes conditions, toutefois, il est possible d'améliorer sensiblement la qualité de l'affichage et l'ergonomie du système en mettant un peu la main à la pâte. Cette section entreprend donc de décrire la structure du fichier de configuration xorg.conf et les principales options que l'on peut utiliser. D'autre part, il peut être instructif de connaître la nature des informations que ce fichier contient, et quelles sont les conséquences des choix effectués dans les utilitaires de configuration.

X-C-4-a. Structure générale du fichier xorg.conf▲

Le fichier xorg.conf est constitué d'un certain nombre de sections contenant chacune les options pour une partie de l'architecture de X.org. La configuration de X.org est un sujet ardu, aussi seules les principales sections du fichier xorg.conf seront décrites dans ce document. Vous pouvez vous référer à la page de manuel xorg.conf et à la documentation de X.org pour plus de détails à ce sujet.

Certaines sections peuvent être définies plusieurs fois, avec différents jeux d'options à chaque fois, afin de permettre la définition de plusieurs configurations. Bien entendu, lorsqu'un serveur X tourne, une seule configuration est utilisée. Cette configuration est spécifiée soit directement en ligne de commande lors du lancement du serveur X, soit en indiquant une configuration par défaut dans le fichier de configuration.

D'autres sections sont globales, et contiennent les options de configuration générales du serveur X. Ces options concernent typiquement l'environnement dans lequel il est supposé fonctionner, et les options qui ne dépendent pas de la configuration utilisée.

La première section globale est la section « Files », qui porte relativement mal son nom, car au lieu de fichiers, elle indique les chemins vers les différentes ressources que le serveur X peut utiliser. Ces ressources comprennent les polices de caractères, l'emplacement des modules complémentaires et l'emplacement des fichiers de définitions de couleurs.

La deuxième section globale est la section « ServerFlags ». Cette section contient les options générales à utiliser par défaut pour tous les serveurs X. Elles permettent d'activer ou de désactiver certaines fonctionnalités ou extensions non standards. Ces options fournissent des valeurs par défaut, elles peuvent être modifiées pour chaque serveur X de manière indépendante si nécessaire.

La troisième section globale est la section « Module ». Cette section contient les commandes de chargement des différents modules du serveur X, lorsque ce serveur est compilé sous forme modulaire. Chaque module gère une certaine partie des fonctionnalités, et celles-ci peuvent donc être activées ou désactivées au niveau de cette section.

Viennent ensuite les sections de configuration des displays. Ces sections décrivent chacune un des aspects du display, et peuvent apparaître en de multiples exemplaires.

Le premier type de section de configuration des displays regroupe toutes les sections qui définissent les périphériques d'entrée de données (clavier, souris, table de digitalisation, etc.). Ces sections sont toutes nommées « InputDevice ».

Le deuxième type de section de configuration contient la définition des adaptateurs graphiques. Ces sections permettent de donner les renseignements nécessaires pour la configuration des différentes cartes graphiques installées sur le système. Elles sont toutes nommées « Device ».

Viennent ensuite les sections « Monitor » qui, comme leur nom l'indique, permettent de définir les caractéristiques physiques des différents moniteurs utilisables. Encore une fois, il peut exister plusieurs sections de ce type, pour définir plusieurs moniteurs dans les configurations multitêtes.

Normalement, chaque moniteur est, en fonction de ses capacités, capable de gérer différents modes graphiques. Les sections « Monitor » peuvent donc contenir des définitions de modes graphiques, mais ce n'est pas la technique recommandée. En effet, il est possible d'utiliser plusieurs moniteurs avec des modes graphiques identiques, aussi X.org donne-t-il la possibilité de définir les modes graphiques en dehors des sections « Monitor » (ce n'est toutefois pas une obligation). Dans ce cas, les modes graphiques seront définis dans des sections nommées « Modes », et celles-ci seront référencées par les sections des moniteurs qui les utilisent.

Les moniteurs sont faits pour être branchés sur des cartes graphiques. Comme on l'a vu ci-dessus, il est possible de définir plusieurs sections « Device » et plusieurs sections « Monitor », afin de décrire plusieurs cartes graphiques et plusieurs moniteurs. Il faut donc spécifier quels moniteurs sont connectés à quelles cartes graphiques. C'est exactement le rôle des sections « Screen ». Pour X.org, un écran n'est donc rien d'autre qu'un couple fonctionnel moniteur / carte graphique. Notez que certaines cartes graphiques haut de gamme peuvent prendre en charge plusieurs écrans. Dans ce cas, il faudra définir plusieurs sections « Device » pour la même carte graphique, et spécifier les ports de sortie dans les options de ces sections.

Enfin, il ne reste plus qu'à définir le display lui-même. Nous avons déjà défini la notion de display ci-dessus comme étant le regroupement d'un clavier, d'une souris et d'un ou plusieurs écrans. Ces associations sont donc définies dans des sections nommées « ServerLayout ». Une section de ce type contient donc nécessairement une référence à une section « InputDevice » pour le clavier et une section « InputDevice » pour le périphérique de pointage, et une ou plusieurs sections « Screen » pour les écrans utilisés par le serveur X. Dautre part, comme leur nom l'indique, les sections « ServerLayout » permettent également de spécifier la disposition relative des écrans les uns par rapport aux autres, dans le cas des configurations multitêtes.

Nous allons à présent décrire un peu plus en détail les différentes sections qui ont été présentées ici. Toutes ces sections sont introduites par le mot clé « Section » suivi du type de la section, indiqué entre guillemets, et se terminent toutes par le mot clé « EndSection ». Entre ces deux balises, un certain nombre d'informations peuvent être spécifiées, et peuvent même être regroupées en sous-sections. Étant donné le grand nombre d'options qui peuvent être indiquées dans les sections du fichier xorg.conf, seules les plus classiques seront décrites ci-dessous.

X-C-4-b. Section « Files »▲

La section « Files », contient les chemins vers les ressources utilisés par X.org. Ce peut être les répertoires de polices de caractères, les répertoires d'installation des modules du serveur X, ou encore des chemins indiquant l'adresse et le port de serveurs de polices sur un réseau. Cette section est donc relativement riche de renseignements pour le serveur X. Un exemple typique de section « Files » est donné ci-dessous :

Sélectionnez

Section "Files"
    RgbPath     "/usr/share/X11/rgb"
    FontPath    "/usr/share/fonts/local"
    FontPath    "/usr/share/fonts/misc"
    FontPath    "/usr/share/fonts/75dpi"
    FontPath    "/usr/share/fonts/100dpi"
    ModulePath  "/usr/lib/modules"
EndSection

Les chemins indiqués sont des chemins Unix classiques, et sont introduits par les mots clés « FontPath », « RgbPath » et « ModulePath » respectivement pour les chemins sur les répertoires de polices, les répertoires de fichiers de définition de couleurs et les répertoires d'installation des modules. Cependant, comme on le verra plus loin, l'accès aux serveurs de polices se fait à l'aide d'une syntaxe de chemin particulière.

X-C-4-c. Section « ServerFlags »▲

Cette section regroupe les principales options globales de tous les serveurs X. Ces options sont généralement introduites à l'aide du mot clé « Option », suivi du nom de l'option entre guillemets, lui-même suivi d'une éventuelle valeur pour cette option, elle aussi entre guillemets. Par exemple, l'option :

Sélectionnez

Option "DontZap"

permet d'empêcher que l'utilisateur puisse utiliser la combinaison de touches CTRL+ALT+BACKSPACE (en temps normal, cette combinaison de touches a pour conséquence de tuer le serveur X, et de forcer la déconnexion de toutes les applications en cours de fonctionnement).

De même, l'option :

Sélectionnez

Option "Dont Zoom"

désactive les combinaisons de touches CTRL+ALT+PLUS et CTRL+ALT+MINUS, où PLUS et MINUS sont respectivement les touches plus et moins du pavé numérique. Ces deux combinaisons de touches sont normalement utilisées respectivement pour passer d'un mode vidéo au suivant ou au précédent.

Il existe beaucoup d'autres options générales du serveur X. Les plus intéressantes sont sans doute les options « BlankTime », « StandbyTime », « SuspendTime » et « OffTime », qui permettent de contrôler les durées des économiseurs d'écran matériels. Vous trouverez la description des autres options dans les fichiers xorg.conf générés automatiquement, et bien entendu dans la page de manuel xorg.conf.

X-C-4-d. Section « Module »▲

Cette section contient la liste des modules que les serveurs X doivent charger lorsqu'ils démarrent. Ces modules peuvent être spécifiés de deux manières différentes, une abrégée et une plus complète. La forme abrégée utilise le mot clé « Load », suivi du nom du module entre guillemets. Par exemple, la ligne suivante permet de demander le chargement du module de gestion des polices TrueType :

Sélectionnez

Load "freetype"

La forme complète utilise une sous-section, introduite par le mot clé « SubSection » suivi du nom du module entre guillemets, et se terminant par le mot clé « EndSubSection ». Ces sous-sections ont la même structure que les sections normales, et permettent de spécifier des options pour le module à l'aide du mot clé « Option ». Par exemple, les extensions du serveur X peuvent être chargées à l'exception de l'extension DGA à l'aide de la sous-section suivante :

Sélectionnez

SubSection "extmod"
    Option "omit X.org-DGA"
EndSubSection

Note : L'extension DGA permet aux applications d'accéder directement à la mémoire vidéo de la carte graphique. La désactiver accroît donc la sécurité du système, mais peut empêcher certaines applications de fonctionner correctement. C'est le cas des jeux, et surtout des programmes de télévision sous XWindow. Par conséquent, il est probable que vous vouliez laisser ces extensions activées. Dans ce cas, il suffit de ne pas spécifier l'option omit de l'exemple précédent.

Outre les modules freetype et extmod donnés dans les exemples précédents, vous pourrez peut-être utiliser les modules dri et glx. Ces modules permettent respectivement d'activer les fonctionnalités DRI (abréviation de l'anglais « Direct Rendering Infrastructure ») du noyau et le support de la 3D par OpenGL. Les différentes cartes capables de gérer les fonctionnalités DRI sont celles listées dans la configuration du noyau, que l'on a déjà vue dans la Section 7.3. Notez toutefois que ces fonctionnalités ne sont indispensables pour utiliser le module glx que pour ces cartes. En particulier, les cartes graphiques basées sur les puces NVidia peuvent utiliser le module glx sans charger le module dri, car le pilote fourni par NVidia utilise un autre mécanisme.

X-C-4-e. Section « InputDevice »▲

Les sections « InputDevice » permettent de décrire tous les types de périphériques d'entrée. En pratique, il s'agira souvent de claviers et de souris, mais il est également possible de connecter des périphériques plus exotiques tels que les joysticks et les tablettes de dessin.

Les sections « InputDevice » doivent être nommées avec un identificateur unique, introduit par le mot clé « Identifier ». Ce mot clé doit être suivi du nom de la section, donné entre guillemets. C'est ce nom qui sera utilisé pour référencer la section dans les sections « ServerLayout » pour définir les différents displays.

La nature du périphérique d'entrée est ensuite spécifiée par la valeur de l'option « Driver ». En pratique, on utilisera quasiment toujours Keyboard ou Mouse, qui correspondent bien évidemment aux pilotes pour les claviers et les souris.

La suite des options de la section « InputDevice » est fonction de la nature du pilote utilisé. Les options les plus courantes pour un clavier sont données dans l'exemple suivant :

Sélectionnez

Section "InputDevice"
    Identifier  "Clavier 1"
    Driver      "Keyboard"

# L'option suivante permet de spécifier le délai
# avant répétition (en millisecondes) et la vitesse
# de répétition une fois ce délai passé (en caractères
# par seconde) :
    Option      "AutoRepeat" "500 30"

# L'option suivante indique que la définition de clavier
# à utiliser est celle de X.org :
    Option      "XkbRules" "xfree86"

# L'option suivante indique que le modèle de clavier
# utilisé est un clavier 105 touches :
    Option      "XkbModel" "pc105"

# L'option suivante indique que la disposition
# des touches est celle d'un clavier français :
    Option      "XkbLayout" "fr"

EndSection

De même, vous trouverez ci-dessous un exemple typique de section « InputDevice » pour une souris :

Sélectionnez

Section "InputDevice"
    Identifier  "Souris 1"
    Driver      "Mouse"

# L'option suivante indique que la souris est
# une souris de type PS/2 :
    Option      "Protocol" "PS/2"

# L'option suivante indique le fichier spécial
# de périphérique à utiliser pour cette souris :
    Option      "Device" "/dev/psaux"

# L'option suivante indique le nombre de boutons
# de la souris :
    Option      "Buttons" "2"

# L'option suivante demande à X.org d'émuler
# le troisième bouton de la souris par clic
# simultané des deux boutons :
    Option      "Emulate3Buttons"

EndSection

Note : Pour les souris à molette connectées sur port PS/2, vous devrez choisir le protocole « IMPS/2 » au lieu du protocole « PS/2 » et indiquer que la souris a 5 boutons. De plus, vous devrez ajouter l'option « ZAxisMapping » dans la section « InputDevice » de votre souris, et lui donner la valeur « 4 5 ». Cette option permet de rediriger la rotation de la molette sur les événements des boutons 4 et 5 de la souris. De cette manière, vous pourrez utiliser votre molette dans toutes les applications qui gèrent ces deux boutons.

X-C-4-f. Sections « Device »▲

Les sections « Device » contiennent les descriptions des cartes graphiques utilisées. Ces descriptions n'indiquent absolument pas quel est le serveur X utilisé : elles ne contiennent qu'une description du matériel. Notez, encore une fois, qu'il est possible de définir plusieurs sections « Device », qui pourront être utilisées dans les sections « Screen » associant les cartes graphiques aux moniteurs.

Tout comme les sections « InputDevice », les sections « Device » doivent disposer d'un identificateur unique, afin de pouvoir les référencer dans les sections « Screen » qui les utilisent. Cet identificateur est introduit par le mot clé « Identifier » et suivi d'un nom indiqué entre guillemets.

Les sections « Device » peuvent contenir un certain nombre d'options permettant de caractériser la carte graphique et de préciser ses capacités (mémoire, rapidité, adresse sur le bus PCI, etc.). Toutes ces options sont bien entendu spécifiques aux différentes cartes graphiques, et ne seront pas décrites en détail ici.

L'option la plus importante est sans doute l'option « Driver », qui permet d'indiquer le pilote que le serveur X devra charger pour piloter cette carte graphique. C'est à ce niveau qu'il faut surtout ne pas se tromper, puisque la moindre erreur ferait échouer le démarrage du serveur X. En général, les pilotes portent le nom du chipset utilisé par la carte graphique, si bien qu'il n'est pas difficile de déterminer la valeur exacte à utiliser. X.org fournit également deux pilotes génériques vga et vesa, permettant respectivement de prendre en charge les cartes graphiques compatibles avec le standard VGA ou compatibles avec le standard VESA 2.0. Sachez cependant que ces pilotes ne disposent d'aucune accélération matérielle, et que leurs performances sont donc bien inférieures aux pilotes spécialisés pour chaque carte graphique.

Vous trouverez ci-dessous un exemple de section « Device » typique :

Sélectionnez

Section "Device"
    Identifier  "Carte 1"
    VendorName  "CHAINTECH"
    BoardName   "TORNADO I7000"

# Cette option indique au serveur X qu'il doit
# charger le module i740_drv pour piloter cette
# carte graphique :
    Driver      "i740"

# Cette option indique la quantité de mémoire
# vive dont cette carte dispose (en ko) :
    VideoRam    8192
EndSection

Note : Les options des sections « Device » ne sont pas très compliquées à utiliser. Cependant, quelques-unes peuvent poser des problèmes lorsqu'on réalise des configurations multitêtes (c'est-à-dire des configurations disposant de plusieurs écrans). Dans la majorité des cas, il faut installer plusieurs cartes graphiques dans le PC pour pouvoir utiliser plusieurs écrans. En général, on utilise une carte AGP et une ou plusieurs cartes PCI. Il va de soi qu'il faut que chaque pilote utilise la bonne carte, aussi faut-il indiquer, dans chaque section « Device », l'adresse de la carte décrite par la section. Cette adresse est définie à l'aide de l'option « BusID ». Cette option permet de retrouver la carte graphique sur les différents bus systèmes. Les cartes AGP utilisant le même mécanisme d'adressage que les cartes PCI, on utilisera la syntaxe suivante :

Sélectionnez

"PCI:bus:périphérique:fonction"

où bus est le numéro du bus PCI sur lequel se trouve la carte graphique, périphérique est le numéro du périphérique sur ce bus, et fonction est le numéro de la fonction à utiliser pour accéder à ce périphérique. Vous pouvez utiliser la commande lspci pour afficher les caractéristiques des différents bus PCI de votre machine et déterminer les valeurs utilisées par vos cartes graphiques.

Certaines cartes graphiques haut de gamme disposent de plusieurs contrôleurs vidéo et sont donc capables de gérer plusieurs écrans. Pour ces cartes graphiques, le principe de fonctionnement est le même : il faut écrire une section « Device » pour chaque contrôleur vidéo existant. Cependant, étant donné que toutes ces sections s'adressent à la même carte graphique, il est impossible de les distinguer par l'intermédiaire de l'option « BusID ». Dans ce cas, on utilise alors l'option « Screen », suivie du numéro du contrôleur vidéo que la section décrit. Ce numéro doit être donné juste après l'option « Screen », sans guillemets. La numérotation des contrôleurs vidéo commence à 0. C'est cette valeur qui est utilisée pour toutes les cartes graphiques ne disposant que d'un seul contrôleur vidéo.

X-C-4-g. Sections « Monitor »▲

Les sections « Monitor » contiennent les informations descriptives des écrans. Notez qu'il est possible de définir plusieurs sections « Monitor », pour plusieurs écrans potentiels. Cependant, chaque section « Screen » devra utiliser un moniteur et un seul.

Les sections « Monitor » sont certainement les sections les plus importantes du fichier xorg.conf. Elles contiennent en effet toutes les informations concernant les moniteurs et tous les paramètres des modes graphiques utilisés par ces moniteurs. Ces informations sont utilisées par le serveur X pour programmer les signaux vidéo que la carte graphique envoie au moniteur. Il est donc évident que chaque section « Monitor » est spécifique à un modèle de moniteur donné, et que la détermination des valeurs qui doivent y être écrites requiert une bonne connaissance du fonctionnement de ce moniteur et de ses caractéristiques physiques. Vous trouverez une description générale du fonctionnement des moniteurs dans les paragraphes qui suivent. Il est impératif de bien les assimiler si vous désirez créer ou modifier une section « Monitor », car si les informations qui y sont stockées sont erronées, le moniteur correspondant risque d'être gravement endommagé.

Si votre moniteur est un écran plat, le moniteur affiche directement les informations dans son mode vidéo natif. La configuration des modes graphiques au niveau de la carte graphique n'a donc que peu d'influence : seuls la résolution et le nombre de couleurs sont utilisés ici, et l'écran s'adapte aux signaux horizontaux et verticaux fournis par la carte graphique dynamiquement pour reconstituer l'image à afficher dans sa résolution native (moyennant une image plus ou moins nette et des couleurs plus ou moins précises). De ce fait, tous les réglages par défaut sont généralement valides, et la section « Monitor » peut donc être réduite à sa plus simple expression.

En revanche, pour les tubes cathodiques, les signaux envoyés par la carte graphique sont très importants. C'est réellement elle qui définit le mode graphique. Les informations temporelles des signaux horizontaux et verticaux, ainsi que le nombre de couleurs utilisées, sont essentiels pour définir le mode vidéo, tant en résolution qu'en nombre de couleurs utilisées, ou encore en fréquence de rafraîchissement de l'image. La définition des modes vidéo dans ce cas est plus complexe, sauf si les modes définis par défaut vous conviennent.

Le principe de fonctionnement des tubes cathodiques utilisés dans les moniteurs est très simple : à chaque instant, un faisceau d'électrons généré par un canon à électrons vient frapper un point d'une plaque phosphorescente située juste derrière la vitre du moniteur. L'énergie cinétique des électrons du faisceau est transformée en lumière par le phosphore en ce point, qui reste ainsi lumineux tant que le faisceau frappe ce point. Comme un seul faisceau est utilisé pour tous les points de la plaque phosphorescente, il faut déplacer le faisceau de point en point pour pouvoir tous les éclairer. Cela a bien entendu pour conséquence que les points ne restent lumineux que pendant un temps très court. Cependant, nous percevons la luminosité de ce point pendant un temps beaucoup plus long, en raison de la rémanence des cellules de l'œil. Les points de l'écran semblent donc être tous allumés en même temps, bien qu'à chaque instant un seul d'entre eux soit atteint par le faisceau d'électrons. Nous voyons ainsi l'image complète du moniteur.

Le déplacement du faisceau d'électrons est assuré par un champ magnétique généré par des bobinages magnétiques à l'arrière du tube cathodique. Le faisceau balaye l'écran ligne par ligne, de gauche à droite (en regardant le moniteur de face). À chaque fois qu'il atteint le bord gauche, il retourne rapidement vers le début de la ligne suivante, sur le bord droit du moniteur. Ce retour se fait simplement en modifiant brusquement le champ magnétique qui dirige le faisceau. Il va de soi que le faisceau d'électrons est coupé pendant ce retour de balayage, car s'il ne l'était pas, on le verrait traverser l'écran de droite à gauche et perturber ainsi l'image. De plus, le champ magnétique n'est pas facilement contrôlable lorsque le retour du faisceau commence. Par conséquent, il est nécessaire que ce retour se fasse un certain temps après que le bord droit ait été éteint. Si ce n'était pas le cas, l'image serait déformée près des bords du moniteur. Le faisceau électronique continue donc de balayer l'écran sur une petite zone après le bord de l'image, sans émettre de lumière. Cette zone s'appelle le « blanking » horizontal.

De même, le faisceau électronique retourne rapidement en haut de l'écran dès qu'il en atteint le bas. Pour les mêmes raisons que pour les retours de balayage horizontal, le faisceau doit être éteint un peu avant et pendant la modification du champ magnétique lors des retours de balayage vertical. La zone ainsi parcourue par le faisceau après le bord de l'image s'appelle le « blanking » vertical.

Note : Il est possible d'utiliser d'autres méthodes de balayage que celle décrite ci-dessus. En particulier, les modes graphiques entrelacés ne suivent pas ce principe. Dans ces modes, seulement une ligne sur deux est balayée à chaque génération d'image. Les lignes paires sont d'abord affichées pour une première image, puis les lignes impaires sont affichées pour l'image suivante. Ces modes graphiques étaient utilisés lorsque les moniteurs n'étaient pas suffisamment rapides pour afficher une image complète sans que l'on puisse voir le balayage du faisceau d'électrons. De nos jours, il est déconseillé d'utiliser ces modes, car l'image a tendance à trembler du fait de l'écart de luminosité alternatif entre les lignes paires et impaires de l'écran.

Les limitations techniques de la technologie des tubes cathodiques imposent une limite supérieure pour la vitesse de balayage, et une limite inférieure pour la durée des retours de balayage horizontal et vertical, ainsi que pour la durée minimale du blanking. Les caractéristiques techniques des tubes sont donc souvent spécifiées en termes de fréquences de balayage et de durées des signaux de synchronisation. Les vieux moniteurs ne pouvaient supporter qu'un nombre limité de fréquences de balayage, que l'on qualifiait alors de « fixes ». De nos jours, les écrans multisynchrones acceptent toutes les fréquences comprises dans une plage de valeur, et s'adaptent donc aux fréquences des signaux émis par les cartes graphiques.

La fréquence de balayage vertical utilisée dans un mode graphique donné constitue le taux de rafraîchissement de l'écran, c'est-à-dire le nombre de fois que l'image de l'écran est affichée par seconde. Il est évident qu'un taux de rafraîchissement trop faible ne permet pas d'avoir une image agréable à regarder, car elle semble trembler ou clignoter. Un tube cathodique de bonne qualité est donc un tube qui permet d'utiliser de hautes fréquences verticales. Comme il est nécessaire d'afficher toutes les lignes pour afficher une image complète, il va de soi qu'un bon tube doit également être capable d'afficher les lignes rapidement, et donc accepter des fréquences de balayage horizontal élevées. Typiquement, les fréquences de balayage horizontal sont environ mille fois plus élevées que les fréquences de balayage vertical, puisque chaque ligne peut contenir environ mille pixels.

La sensibilité au taux de rafraîchissement dépend des personnes et de l'emploi que l'on fait du tube. Les tubes destinés à être regardés de loin peuvent utiliser des fréquences beaucoup plus faibles que les tubes de proximité. Ainsi, les télévisions affichent 25 images par seconde (en fait, elles affichent 50 demi-images par seconde, car elles utilisent l'entrelacement). En revanche, ce taux de rafraîchissement est très insuffisant pour les moniteurs d'ordinateurs, où la limite inférieure est de 60 Hz. Le standard VESA exige des taux de 72 Hz ou plus pour que l'image soit agréable à regarder, mais de nombreux écrans supportent facilement 85 Hz ou plus de nos jours. Certaines personnes ne sont cependant pas dérangées par des taux aussi faibles que 60 Hz. Il est bon de savoir quel taux de rafraîchissement vous convient, car un balayage insuffisant peut fatiguer vos yeux, même sans que vous en soyez conscient. Et cette fatigue se traduit toujours un jour ou un autre par des maux de tête inexpliqués… Ne vous vantez donc pas de voir le balayage, c'est un grave handicap par rapport à ceux qui ne le voient pas et qui donc ont moins de maux de tête que vous !

Vous pouvez utiliser la méthode suivante pour déterminer si le taux de rafraîchissement est suffisant pour vous. Commencez par afficher une image blanche sur la totalité de la surface visible de votre moniteur. Puis réglez la luminosité du moniteur à son maximum. Placez-vous ensuite de biais par rapport à votre moniteur, et regardez en face de vous. Concentrez ensuite votre attention sur l'image de l'écran, sans le regarder directement (regardez-le « en coin »). Normalement, vous devez percevoir l'image avec les cellules latérales de la rétine, qui donnent une image moins précise que les cellules centrales, mais qui sont plus sensibles aux mouvements (ces cellules nous servent en quelque sorte d'antennes). Ces cellules sont donc plus aptes à percevoir les variations rapides de luminosité de l'image dues au balayage du faisceau électronique. Si l'image semble clignoter, c'est que le taux de rafraîchissement de l'écran est insuffisant. Sinon, vous tenez le bon taux, ne le lâchez pas.

Certaines caractéristiques techniques des tubes cathodiques influent sur les autres et permettent donc de modifier le taux de rafraîchissement. Il est évident que si la durée du retour du faisceau est importante, l'écran ne peut pas générer beaucoup d'images par seconde. Par conséquent, plus la durée du retour de balayage est longue, moins bon peut être le taux de rafraîchissement. Il en va de même pour la durée du blanking. Les bons écrans disposent donc souvent de retours de balayage rapides et de courtes durées de blanking. Mais diminuer ces durées nécessite une électronique plus précise au niveau du contrôle des champs magnétiques dirigeant le faisceau d'électrons. Il est également évident que la résolution du mode graphique influe sur le taux de rafraîchissement. Si la résolution est élevée, il y a plus de pixels à afficher au total sur chaque ligne de l'écran. À vitesse de balayage des pixels fixée, le temps nécessaire pour balayer une ligne est donc plus grand. Et comme il y a plus de lignes à afficher, le temps nécessaire pour générer une image complète est plus grand, et le taux de rafraîchissement est plus faible. Donc, si le test décrit dans le paragraphe précédent vous indique que votre taux de rafraîchissement est trop faible, vous pouvez tenter de baisser la résolution.

Note : Notez que la profondeur de couleur utilisée n'intervient absolument pas dans le taux de rafraîchissement. Cette profondeur n'est un facteur limitant qu'au niveau de la carte graphique, qui peut ne pas avoir assez de mémoire pour afficher un mode de grande résolution avec toutes les couleurs désirées ou ne pas avoir une électronique assez rapide pour traiter toutes les données à une vitesse raisonnable.

Le signal vidéo émis par la carte graphique contient toutes les informations dont le moniteur a besoin pour générer l'image. Ces informations spécifient bien entendu l'intensité du faisceau d'électrons, mais aussi les signaux de synchronisation qui contrôlent les retours de balayage horizontal et vertical. Ce sont les informations de synchronisation que les sections « Monitor » du fichier xorg.conf contiennent. On comprend donc l'importance de ces informations pour la qualité de l'image, aussi bien en terme de stabilité qu'en termes de taux de rafraîchissement.

Les sections « Monitor » sont constituées grosso modo de deux parties. La première partie contient les caractéristiques générales de l'écran, telles que son nom, son modèle et le nom de son fabricant. Elle contient également les plages de fréquences de balayage horizontal et vertical. La deuxième partie contient les définitions des modes graphiques, à raison d'une ligne par mode graphique utilisable. La documentation de X.org appelle ces lignes des « lignes de mode » (« modelines » en anglais). Il est évident que les informations fournies dans les lignes de mode sont très sensibles, et déterminent tous les paramètres du mode graphique : résolution, position et taille de l'image sur l'écran, taux de rafraîchissement.

La première partie d'une section « Monitor » ressemble à ceci :

Sélectionnez

Section "Monitor"
    Identifier "Moniteur 1"
# Marque et modèle du moniteur (informations facultatives) :
    VendorName "SONY"
    ModelName     "MULTISCAN 100ES"
# Plage de fréquence horizontale (information capitale) :
    HorizSync     30-70
# Plage de fréquence verticale (information capitale) :
    VertRefresh   50-120

Le mot clé « Identifier » permet de donner un nom à la section « Monitor ». Ce sera ce nom que l'on utilisera plus loin dans la section « Screen » pour indiquer que l'on désire utiliser ce moniteur. Les mots clés « VendorName » et « ModelName » permettent de donner la description du moniteur. Les informations stockées ici n'ont aucun effet sur la configuration du moniteur et sont simplement indicatives. En revanche, les plages de fréquences horizontales et verticales indiquées respectivement après les mots clés « HorizSync » et « VertRefresh » sont d'une importance capitale. Elles donnent les plages de fréquences auxquelles le moniteur peut travailler, et servent à contrôler la validité des lignes de mode données dans la deuxième partie de la section « Monitor ». Il est donc important de donner ici les valeurs exactes, que vous trouverez normalement dans la fiche technique de votre moniteur (cette fiche est souvent imprimée à la fin du mode d'emploi). Pour les moniteurs multisynchrones, les plages de fréquences utilisables peuvent être données par leurs fréquences minimale et maximale, séparées d'un tiret. Les fréquences fixes peuvent être spécifiées simplement avec une seule valeur. Il est possible de spécifier plusieurs fréquences fixes et plusieurs plages de fréquences en les séparant par des virgules. L'unité utilisée pour les fréquences horizontales est le kilohertz, et celle utilisée pour les fréquences verticales est le Hertz.

La deuxième partie de la section « Monitor » contient les lignes de mode, à raison d'une ligne de mode par mode graphique que le moniteur est capable d'afficher. En général, une ligne de mode ressemble à ceci :

Sélectionnez

Modeline "1024x768" 92.96 1024 1064 1240 1352 768 768 778 802

mais il existe cette une autre syntaxe, beaucoup plus claire, car elle différencie les différentes valeurs données dans la ligne précédente :

Sélectionnez

Mode "1024x768"
    DotClock 92.96
    HTimings 1024 1064 1240 1352
    VTimings 768 768 778 802
EndMode

La première valeur indiquée entre guillemets dans les lignes de mode est le nom du mode graphique. Comme on le verra plus tard, c'est ce nom qui est utilisé pour spécifier les modes graphiques utilisables dans la section « Screen ». La deuxième valeur est la fréquence de base des signaux émis par la carte graphique. Cette vitesse est exprimée en MHz et représente le nombre de pixels par seconde que le faisceau électronique du moniteur balaye. Les quatre valeurs suivantes fixent les paramètres horizontaux du mode graphique : résolution horizontale, pixel à partir duquel le signal de synchronisation pour le retour de balayage horizontal commence, pixel auquel ce signal s'arrête et longueur totale de la ligne en pixel, blanking compris. De même, les quatre dernières valeurs fixent les paramètres verticaux du mode graphique, à savoir résolution verticale, ligne de début et ligne de fin du signal de synchronisation pour le retour de balayage vertical, et nombre de lignes total du mode graphique. On notera que les informations concernant le signal de synchronisation du balayage horizontal sont toutes multiples de 8. Cette contrainte est imposée par le matériel de la plupart des cartes graphiques. D'autre part, l'unité utilisée pour ces valeurs est le pixel. Il faut donc se baser sur la fréquence de base indiquée au début de la ligne de mode pour les convertir en temps. Les informations concernant le signal de synchronisation vertical, quant à elles, sont exprimées en nombre de lignes. Elles peuvent ne pas être multiples de 8. La conversion en temps se calcule cette fois à partir de la fréquence de base et de la longueur totale d'une ligne horizontale pour ce mode graphique. Enfin, il est possible de rajouter des options complémentaires à la fin des lignes de mode pour préciser le fonctionnement du mode graphique, à l'aide du mot-clef « Flags ». L'option la plus courante étant sans aucun doute « Interlace », qui permet de créer des modes entrelacés. L'option « Doublescan » quant à elle permet de faire en sorte que chaque ligne est affichée deux fois de suite. Elle permet de créer des modes graphiques de faible résolution, qui utilisent des fréquences de balayage trop faibles pour les moniteurs actuels. Vous pourrez trouver les autres options dans la page de manuel xorg.conf.

La section « Monitor » se termine, comme toute section du fichier xorg.conf, par une ligne de fin de section :

Sélectionnez

EndSection

Comme vous vous en êtes aperçu, les données stockées dans les lignes de mode sont assez techniques. Quelques explications complémentaires ne seront donc pas de trop pour comprendre l'influence de ces paramètres et pour créer de nouvelles lignes de mode.

Pour commencer, la fréquence de base de la ligne de mode doit évidemment être gérée par la carte graphique. Vous pouvez déterminer la fréquence de base maximale en regardant les informations affichées par le serveur X adapté à cette carte lorsqu'il démarre. Cette information est toujours juste, même si les lignes de mode écrites dans votre fichier xorg.conf ne conviennent pas et que le serveur X ne démarre pas correctement. La ligne contenant cette fréquence maximale est semblable à celle-ci :

Sélectionnez

Maximum allowed dot-clock: 163.000 MHz

Cette fréquence de base peut être générée par la carte graphique, mais il n'est pas certain qu'elle soit supportée par le moniteur. En effet, les moniteurs ne sont pas capables de gérer les fréquences de base au-delà d'une certaine limite. La gamme de fréquences qu'ils acceptent est ce que l'on appelle leur bande passante. La fréquence de base doit donc être dans cette bande passante, c'est-à-dire qu'elle doit être inférieure à la fréquence maximale que le moniteur peut gérer. La bande passante de votre moniteur est normalement indiquée dans sa fiche de spécifications techniques. Si toutefois ce n'est pas le cas, vous pouvez vous faire une idée de la fréquence la plus élevée de cette bande passante en regardant la résolution maximale qu'il peut afficher et en consultant ce tableau :

Tableau 10-1. Fréquence maximale des moniteurs

Résolution	Fréquence maximale
640x480	25
800x600	36
1024x768	65
1280x1024	110
1600x1200	185

Les valeurs des fréquences indiquées dans ce tableau sont les plus petites valeurs constatées pour l'ensemble des moniteurs gérés par X.org. On peut donc supposer que votre moniteur gère ces fréquences, et certainement même de plus hautes.

La résolution du mode graphique est donnée par la première des quatre valeurs des paramètres horizontaux et verticaux dans la ligne de mode. Ainsi, dans la ligne de mode exemple donnée ci-dessus, la résolution horizontale est de 1024 et la résolution verticale est de 768. Sachez que vous êtes parfaitement libre d'utiliser des résolutions non standards, en écrivant les lignes de mode correspondantes. Dans l'exemple donné ci-dessus, il s'agit simplement du mode graphique 1024x768. Notez, encore une fois, que la profondeur de couleur n'intervient absolument pas dans les paramètres du moniteur. Ils n'interviennent que dans les composants de la carte graphique qui sont chargés de générer les signaux vidéo pour le moniteur.

La quatrième valeur des paramètres horizontaux donne la longueur totale des lignes physiques dans ce mode. Cette longueur comprend bien entendu la partie visible de l'image, mais également la partie due au blanking horizontal. Rappelons que le blanking est la partie balayée par le faisceau alors qu'il est éteint, ce qui comprend la partie balayée pendant la durée du signal de synchronisation horizontal. Dans l'exemple donné ci-dessus, le blanking a une longueur égale à 1352-1024 pixels, soit 328 pixels. La quatrième valeur des paramètres verticaux fixe de même le nombre de lignes total du mode, en tenant compte des lignes du blanking vertical.

Comme vous pouvez le constater dans la ligne de mode exemple, le pixel auquel le signal de synchronisation commence n'est pas le dernier pixel visible. En effet, il y a 40 pixels d'écart entre le dernier pixel visible (en l'occurrence, le pixel 1024) et le pixel auquel le signal de synchronisation horizontal commence (le pixel 1064). Cet espace fait partie du blanking, il sert de marge pour éviter les perturbations dues au retour de balayage et pour positionner l'image sur l'écran. Cette zone noire se trouve au-delà du bord droit de l'image affichée. Elle est suivie par la zone qui serait balayée pendant la durée du retour de balayage si le faisceau poursuivait sa route au lieu de revenir sur le bord gauche. Cette zone se termine au pixel indiqué par la troisième valeur (1240 dans notre exemple). Ce pixel est donc toujours positionné sur le point le plus à droite que le moniteur peut afficher. Par conséquent, la taille de la partie du blanking situé à la droite de l'image est égale au numéro du pixel où le signal de synchronisation horizontal se termine moins le nombre de pixels affichés. Dans notre exemple, cette partie de blanking a une taille de 1240-1024 pixels, soit 216 pixels. La taille de la partie du blanking horizontal situé à la gauche de l'écran est donc logiquement égale à la longueur totale de la ligne (1352) moins le pixel où le signal de synchronisation se termine (1240), ce qui donne 112 pixels. Vous voyez ainsi que l'on peut décaler l'image vers la gauche en augmentant les valeurs de départ et de fin du signal de synchronisation. Inversement, on peut décaler l'image vers la droite en diminuant ces valeurs.

Le même raisonnement peut être appliqué aux paramètres verticaux du mode graphique. Le blanking vertical comprend les lignes balayées avant et après le signal de synchronisation, ainsi que les lignes balayées pendant le temps où ce signal est généré. La dernière ligne de ce signal est, encore une fois, la ligne la plus basse que le moniteur peut afficher. On peut donc déplacer l'image vers le haut ou vers le bas en jouant sur les valeurs de départ et de fin du signal de synchronisation vertical dans les paramètres verticaux du mode graphique.

En augmentant le nombre de pixels physiques pour chaque ligne et en conservant la même résolution, la largeur de l'image visible est réduite. En effet, la proportion de la partie visible de l'image sur la largeur totale de l'écran est d'autant plus faible que le nombre de pixels physiques des lignes est grand. Le même raisonnement peut être appliqué sur les paramètres verticaux. L'image peut donc être agrandie ou réduite horizontalement et verticalement en jouant sur la longueur totale des lignes et sur la hauteur totale de l'image. Si l'on veut que l'image reste centrée, il faut également décaler les points de début et de fin des signaux de synchronisation, pour que la proportion du blanking placée de part et d'autre de l'image reste constante.

Il faut bien comprendre que la modification des paramètres de synchronisation et de la longueur totale de la ligne est soumise à de fortes contraintes. Il faut s'assurer que les durées des signaux de synchronisation et du blanking restent dans les limites de ce que peut accepter le moniteur. De plus, le nombre de points balayés au total est évidemment le produit de la longueur totale des lignes et du nombre de lignes total du mode. À fréquence de base fixe, cela revient à définir le taux de rafraîchissement, puisque plus il y a de pixels à balayer dans chaque image, moins il est possible d'afficher d'images par seconde. Cela n'est pas gênant si vous pouvez augmenter la fréquence de base. Par contre, si vous avez atteint la limite de votre carte graphique, ou la limite de bande passante de votre moniteur, vous serez limité dans le taux de rafraîchissement si vous devez réduire les dimensions de l'image affichée.

Vous devez vous en douter à présent : l'écriture d'une ligne de mode est un sport très difficile. La technique à utiliser est itérative. Vous pouvez tourner en rond pendant un certain temps, si vous ne savez pas vous y prendre. La première des choses à faire est de choisir la dimension de l'image que vous désirez obtenir. Cette dimension va fixer la largeur totale et le nombre de lignes total qui seront utilisés pour ce mode graphique. Vous pouvez toujours partir des lignes de mode utilisées pour les modes graphiques VESA pour un moniteur semblable au vôtre. Une fois que vous aurez ces valeurs, vous pourrez essayer de faire monter le taux de rafraîchissement en augmentant la fréquence de base. Vous aurez peut-être à redimensionner et à recentrer l'image sur le moniteur. Les quatre contraintes à respecter lorsque vous augmentez la fréquence de base sont bien entendu la durée du blanking horizontal et vertical, la durée des signaux de synchronisation et les plages de fréquences horizontales et verticales acceptées par votre moniteur. Il est probable que vous aurez à accroître l'écart entre les valeurs de début et de fin des signaux de synchronisation, car leur durée peut baisser dangereusement lorsque la fréquence de base augmente. Malheureusement, cela peut vous limiter dans la possibilité de centrer l'image sur votre moniteur. Une image dont les bords ne sont pas rectilignes ou pas nets est un signe indiquant que le signal de synchronisation n'est pas suffisamment long. Si vous ne vous en sortez pas, c'est que vous essayez d'atteindre un taux de rafraîchissement trop élevé.

Si vous désirez fabriquer un mode graphique de résolution non standard, vous ne trouverez pas forcément une ligne de mode pouvant servir de point de départ. Dans ce cas, il va vous falloir créer cette ligne de mode ex-nihilo. Vous trouverez dans le fichier de documentation VideoModes.doc de X.org les explications permettant de créer une ligne de mode correcte à partir des caractéristiques de votre moniteur. Pour les moniteurs multisynchrones, la technique suivante peut être utilisée.

La première étape est de trouver la bande passante de votre moniteur et les plages de fréquences horizontales et verticales utilisables par votre moniteur. Ces données sont très souvent fournies dans la documentation du moniteur. Par exemple, pour un moniteur Sony Multiscan 100ES, ces plages de fréquences sont les suivantes :

	Horizontales (kHz)	Verticales (Hz)
Fréquence minimale	30	50
Fréquence maximale	70	120

La deuxième étape est de choisir la résolution que l'on désire utiliser. Supposons que l'on veuille utiliser une résolution intermédiaire entre 1024x768 et 800x600 sur ce type d'écran 15 pouces. Prenons par exemple 904x678. Notez que la résolution horizontale est divisible par 8, et que la résolution verticale est égale aux trois quarts de cette dernière. Ce rapport permet simplement de conserver la proportion de 4/3 des écrans d'ordinateur. Pour pouvez cependant choisir un autre rapport si vous le désirez.

Vous devez ensuite déterminer les longueurs totales des lignes en pixels et le nombre total de lignes, blanking compris. C'est cette partie qui est la plus difficile, elle nécessite de connaître les durées minimales des signaux de synchronisation horizontaux et verticaux. Ces données sont hélas rarement fournies par les fabricants. Heureusement, on peut s'en passer en pratique, car tous les écrans cathodiques utilisent la même technologie. En général, la longueur totale d'une ligne est égale à la résolution horizontale divisée par 0,8, et le nombre total de lignes est égal à la résolution verticale augmentée de 5 %. Pour notre mode graphique, le calcul est donc le suivant :

Sélectionnez

longueur totale des lignes = 904 pixels / 0,8 = 1130 pixels
hauteur totale de l'image = 678 lignes * (1+5/100) =
    678 lignes * 1,05 = 711,9 lignes.

La longueur totale des lignes n'est pas multiple de 8, nous devons donc l'arrondir à 1136. De même, la hauteur totale de l'image doit être arrondie à 712 lignes.

Nous disposons à présent des premières et dernières valeurs des paramètres horizontaux et verticaux de la ligne de mode. Les paramètres intermédiaires, qui fixent le début et la fin des signaux de retour de balayage, doivent être choisis de telle sorte que ces signaux commencent un peu après le début du blanking et se terminent un peu avant le début de la génération de l'image suivante. En pratique, on peut couramment considérer qu'une marge de 32 à 40 pixels est suffisante pour les signaux de synchronisation horizontaux, et qu'il faut 0 à 10 lignes pour les signaux de synchronisation verticaux. L'écart entre le début et la fin de ces signaux doit être suffisamment grand pour garantir leurs durées minimales exigées (mais a priori inconnues) par votre moniteur. Dans notre exemple, nous pouvons donc choisir les paramètres suivants :

Sélectionnez

    HTimings 904 944 1096 1136
    VTimings 678 683 707 712

Il reste à déterminer la fréquence de base à utiliser. Le but est bien entendu d'obtenir le taux de rafraîchissement le plus élevé possible, donc la fréquence de base la plus élevée, tout en restant dans les limites de la carte graphique et du moniteur. La contrainte la plus forte en général est la fréquence maximale de balayage horizontal.

Dans notre cas, l'écran est capable de travailler à 70 kHz au plus, c'est-à-dire d'afficher 70000 lignes par seconde. Comme notre mode graphique utilise 712 lignes physiques au total, cela nous donne un taux de rafraîchissement de 70000/712, soit environ 98 images par seconde. Bien entendu, il faut contrôler que cette fréquence est bien dans la plage de fréquences verticales du moniteur. C'est bien le cas ici, puisqu'il peut supporter des fréquences allant jusqu'à 120 Hz. En général, il faut prendre la plus petite de ces valeurs comme taux de rafraîchissement initial.

Une fois le taux de rafraîchissement déterminé, nous devons calculer la fréquence de base à utiliser. Pour afficher 98 images de 710 lignes de 1125 pixels par seconde, nous calculons cette fréquence de la manière suivante :

Sélectionnez

98 * 712 * 1136 = 79,26 MHz

Encore une fois, il faut contrôler que la carte graphique peut générer un signal de cette fréquence et que celle-ci est bien inférieure à la bande passante du moniteur. Dans le cas contraire, il faudrait encore une fois se limiter à la plus petite de ces valeurs. La plupart des cartes graphiques récentes peuvent monter au moins jusqu'à 150MHz, et l'écran Sony Multiscan 100ES a une bande passante bien supérieure à cette valeur. Nous pouvons donc conserver cette fréquence de base, et obtenons donc la ligne de mode suivante :

Sélectionnez

Mode "904x678"
    DotClock 79.26
    HTimings 904 944 1096 1136
    VTimings 678 683 707 712
EndMode

Cette ligne de mode a peu de chances d'être satisfaisante sans retouches, mais elle peut servir de point de départ pour la recherche de la ligne de mode idéale. En général, les paramètres étant choisis proches de l'optimum, l'image sera bien trop grande ou déformée sur les bords. Vous devrez donc faire des ajustements manuels pour vous rapprocher, petit à petit, d'une ligne de mode utilisable. Vous pourrez utiliser l'utilitaire xvidtune pour cela. Cet utilitaire est un utilitaire fourni avec X.org, qui permet de modifier les dimensions et la position de l'image interactivement. Cet utilitaire fonctionne directement sous XWindow, et permet donc d'avoir un aperçu de l'image avec les paramètres modifiés. Vous trouverez une description plus détaillée de la manière d'utiliser xvidtune dans la Section 10.3.6.

Seul le redimensionnement de l'image modifie le nombre total de lignes et leur longueur totale. En particulier, la réduction de la taille de l'image accroît la taille totale des lignes et leur nombre, ce qui entraîne la baisse du taux de rafraîchissement. À chaque fois que vous réduisez l'image, vous pourrez recalculer le taux de rafraîchissement et la fréquence de base nécessaire pour atteindre ce taux, tout en veillant à ne dépasser ni les limites de votre carte graphique ni celles de votre moniteur.

Ainsi, après quelques modifications de la ligne de mode dans xvidtune et réajustements de la fréquence de base, la ligne de mode suivante peut être obtenue :

Sélectionnez

Mode "904x678"
    DotClock 79.82
    HTimings 904 920 1104 1144
    VTimings 678 679 710 712
EndMode

Cette ligne de mode permet d'obtenir un affichage correct en 904 par 678, avec un taux de rafraîchissement de 97.99 Hz, ce qui est plus qu'honorable. On constate que la première ligne de mode utilisait une durée de balayage vertical trop petite, ce qui provoquait des déformations sur les bords de l'image.

Si vous voulez approfondir le sujet, vous pouvez lire les formules mathématiques donnant les relations entre les différents paramètres techniques influant sur la génération des images dans l'Annexe C. Ces formules sont données à titre indicatif, elles ne vous donneront pas les caractéristiques techniques de votre écran. Encore une fois, je ne saurais trop vous recommander d'utiliser les outils fournis avec votre distribution…

X-C-4-h. Sections « Modes »▲

Généralement, les lignes de mode sont définies pour un moniteur donné, car l'apparence de l'image dépend des caractéristiques physiques de chaque moniteur. Par conséquent, ces lignes sont définies la plupart du temps dans les sections « Monitor ». Cependant, il peut être utile de regrouper toutes les lignes de mode d'un type de moniteur donné dans une section à part, afin de structurer et d'organiser le fichier xorg.conf.

Pour cela, on écrira des sections « Modes », qui n'auront donc pas d'autre rôle que de contenir une ou plusieurs lignes de mode, et qui seront référencées dans les sections « Monitor » des moniteurs qui désirent utiliser ces lignes de mode. L'intérêt de regrouper toutes les lignes de mode dans une section « Modes » apparaît clairement dès que plusieurs sections « Monitor » utilisent les mêmes lignes de mode. Ce peut être le cas pour des moniteurs d'un même fabricant ou possédant des caractéristiques techniques similaires.

Le format des sections « Monitor » est très simple, puisqu'elles ne contiennent qu'un identificateur, introduit comme à l'accoutumée par le mot-clef « Identifier » suivi du nom de la section entre guillemets, et les lignes de mode elles-mêmes. La syntaxe de ces lignes est exactement la même que celle qui est utilisée dans la section « Monitor » et ne sera donc pas décrite plus en détail ici. Vous trouverez ci-dessous un exemple de section « Modes » :

Sélectionnez

# Exemple de section Modes :
Section "Modes"
    Identifier "Modes Standards"
    Modeline "640x480"    50.00 640 656 720 832 480 480 489 501
    Modeline "800x600"    72.80  800 816 928 1040 600 600 610 626
    Modeline "1024x768"  92.00 1024 1076 1252 1344 768 772 782 806
EnsSection

X-C-4-i. Sections « Screen »▲

Les sections « Screen » permettent de regrouper les moniteurs et les cartes graphiques pour effectuer l'affichage des écrans d'un display, et d'indiquer les modes graphiques que l'on désire utiliser parmi tous les modes que le moniteur indiqué sait gérer, pour chaque profondeur de couleur.

Les sections « Screen » sont, comme les sections « Monitor », constituées de deux parties. La première partie spécifie les informations générales de l'écran, à savoir essentiellement la carte graphique et le moniteur à utiliser. La deuxième partie quant à elle permet de préciser, pour chaque profondeur de couleur utilisable avec cet écran, les résolutions des modes graphiques utilisables ainsi que les paramètres des résolutions virtuelles. Voici trouverez ci-dessous un exemple de section « Screen » :

Sélectionnez

Section "Screen"
    Identifier "Ecran 1"
    Device      "Carte 1"
    Monitor     "Moniteur 1"
    DefaultDepth 24
    SubSection "Display"
        Depth  24
        Modes  "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection "Display"
        Depth  16
        Modes  "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection "Display"
        Depth  8
        Modes  "1024x768" "800x600" "640x480"
    EndSubSection
EndSection

L'option « Identifier » permet, comme d'habitude, de nommer la section « Screen » courante. Le nom doit être indiqué entre guillemets, à la suite du mot clé « Identifier ». C'est ce nom qui sera utilisé dans les sections « ServerLayout » pour référencer les écrans du display. Le mot-clef « Device » indique la section « Device » à utiliser pour obtenir les informations sur la carte graphique qui gère l'affichage de cet écran. Il doit être suivi du nom qui a été spécifié après le mot-clef « Identifier » dans la section « Device » correspondante. De même, le mot-clef « Monitor » indique la section « Monitor » à utiliser pour obtenir les informations sur le moniteur courant. Enfin, le mot-clef « DefaultColorDepth » indique la profondeur de couleur utilisée par défaut au démarrage de XWindow. Comme nous le verrons plus loin, une autre profondeur de couleur que celle-ci pourra être utilisée en passant un argument sur la ligne de commande du serveur X.

Comme vous pouvez le voir, la section « Screen » contient une ou plusieurs sous-sections « Display ». Ce sont ces sous-sections qui indiquent les paramètres de l'écran spécifiques à chaque profondeur de couleur utilisable. Les sous-sections « Display » contiennent les informations suivantes :

la profondeur de couleur considérée, exprimée en bits par pixels après le mot-clef « Depth » ;
la liste des modes graphiques utilisables avec cette profondeur de couleur, référencés par le nom de leur ligne de mode, après le mot-clef « Modes ». Plusieurs modes peuvent être spécifiés, en donnant leurs noms respectifs, séparés par des espaces.
des informations complémentaires concernant les résolutions virtuelles pour les modes dans lesquels la résolution logique de l'écran est supérieure à la résolution réellement utilisée. Ces paramètres indiquent la résolution logique de l'écran virtuel, ainsi que le positionnement de l'image affichée par l'écran physique dans cet écran virtuel. Vous trouverez de plus amples informations sur ces options dans la page de manuel xorg.conf.

X-C-4-j. Sections « ServerLayout »▲

Le dernier type de section, qui regroupe toutes les informations des sections vues précédemment, est le type des sections « ServerLayout ». Comme leur nom l'indique, les sections de ce type fournissent les informations concernant la disposition des écrans d'un display. Cependant, dans la plupart des cas, les displays n'ont qu'un seul écran, et il est évident que la disposition de cet écran est triviale dans ce cas.

Il peut exister plusieurs sections « ServerLayout » dans le fichier xorg.conf. En effet, ce fichier peut être utilisé par plusieurs serveurs X qui peuvent tourner simultanément sur la même machine (que l'on ait plusieurs cartes graphiques ou non). Chaque serveur X peut donc utiliser une section « ServerLayout ». La section utilisée par défaut est la première que le serveur X trouvera dans le fichier xorg.conf, mais il est possible de lui demander d'en utiliser une autre à l'aide d'une option en ligne de commande. Toutefois, encore une fois, la plupart des machines ne disposent que d'un seul écran, et même si l'on lance plusieurs serveurs X, il n'y a ici besoin que d'une seule section « ServerLayout ».

Les sections « ServerLayout » indiquent surtout au serveur X quels sont les périphériques d'entrée à utiliser (au moins un clavier et une souris) en plus de l'écran ou les écrans du display. Ce sont donc ces sections qui définissent complètement un display donné. L'exemple donné ci-dessous présente une section « ServerLayout » simple :

Sélectionnez

Section "ServerLayout"
    Identifier "Serveur 1"
    Screen "Ecran 1"
    InputDevice "Clavier 1" "CoreKeyboard"
    InputDevice "Souris 1" "CorePointer"
    Option "BlankTime" "5"
EndSection

Les sections « ServerLayout » disposent d'un nom qui permet de les identifier. Ce nom est le nom qui sera utilisé dans la ligne de commande du serveur X si plusieurs sections « ServerLayout » sont définies. Il doit être indiqué, comme d'habitude, à la suite du mot-clef « Identifier », entre guillemets.

Les sections « ServerLayout » doivent ensuite indiquer au moins un écran pour le display qu'elles décrivent. Les écrans sont introduits à l'aide du mot-clef « Screen », suivi de l'identificateur de la section « Screen » à utiliser. Si plusieurs écrans doivent être utilisés, il est possible de spécifier la position des écrans les uns par rapport aux autres à l'aide d'options complémentaires, qui sont spécifiées à la suite de l'identificateur de l'écran. Ces options permettent de positionner les écrans relativement les uns aux autres, ou de manière absolue en précisant leurs coordonnées dans le système de coordonnées de l'écran virtuel. Les options les plus simples à utiliser sont les options RightOf, LeftOf, Above et Below, qui permettent d'indiquer respectivement que l'écran courant est situé à droite, à gauche, au-dessus ou en dessous de l'écran dont l'identificateur est spécifié juste après. Par exemple, si l'on veut rajouter un deuxième écran à la section précédente, et que cet écran doit être situé à droite du premier écran, on ajoutera simplement la ligne suivante :

Sélectionnez

    Screen "Ecran 2" RightOf "Ecran 1"

La section « ServerLayout » doit ensuite contenir au moins une référence à un clavier et une référence à un périphérique de pointage. Ces références sont introduites à l'aide du mot-clef « InputDevice », suivi de l'identificateur de la section « InputDevice » à utiliser. Le serveur X doit interpréter les événements provenant des différents périphériques d'entrée correctement. Il faut en particulier lui indiquer quels sont les périphériques principaux à l'aide de l'option CorePointer pour la souris principale et l'option CoreKeyboard pour le clavier principal. Seuls les périphériques d'entrée principaux seront utilisés en tant que clavier et en tant que souris.

Enfin, comme vous pouvez le voir dans l'exemple donné ci-dessus, il est possible d'utiliser des options spécifiques pour chaque section « ServerLayout ». Ces options sont les mêmes que celles utilisées dans la section « ServerFlags ». Vous pouvez donc ici spécifier une autre valeur que celles indiquées dans cette section, afin de préciser le comportement d'un serveur spécifique. Dans l'exemple donné ci-dessus, l'économiseur d'écran a été réglé pour s'activer au bout de 5 minutes.

X-C-5. Informations utilisées lors du démarrage de X.org▲

Les informations stockées dans le fichier de configuration xorg.conf sont utilisées par X.org pour déterminer la manière dont l'affichage doit se faire. Lorsque le serveur X démarre, il commence par rechercher la section « ServerLayout » qu'il doit utiliser pour déterminer les principales options du display. Par défaut, il utilisera systématiquement la première section « ServerLayout » du fichier xorg.conf. Cependant, il est possible de lui demander d'en utiliser une autre, à l'aide de l'option de ligne de commande -layout, suivie de l'identificateur de la section à utiliser.

Le serveur X initialise alors tous les écrans du display et prend en charge les périphériques d'entrée. Pour chaque écran, il choisit la profondeur de couleur indiquée dans la variable « DefaultDepth » de la section « Screen » et tente de l'utiliser. Cependant, il est possible de choisir une autre profondeur de couleur à l'aide de l'option -depth, suivie de la profondeur de couleur à utiliser, spécifiée en bits par pixels. Remarquez que dans le cas des configurations à plusieurs écrans, il n'est possible de spécifier qu'une seule profondeur de couleur. Il faut donc que toutes les sections « Screen » des écrans utilisés contiennent une sous-section « Display » pour la profondeur de couleur choisie.

Une fois la profondeur de couleur déterminée, le serveur X choisit pour chaque écran la première résolution indiquée dans la liste des modes de la sous-section « Display » dont la profondeur de couleur correspond à celle utilisée. Il tente alors de passer l'adaptateur graphique dans ce mode graphique, en utilisant pour cela la ligne de mode correspondante à cette résolution pour piloter le moniteur.

Il est possible, lorsque XWindow fonctionne, de changer cette résolution avec les combinaisons de touches CTRL+ALT+PLUS et CTRL+ALT+MINUS (PLUS et MINUS étant les touches + et - du pavé numérique). Ces deux combinaisons de touches permettent respectivement de passer d'une résolution à la suivante ou à la précédente dans la liste des modes spécifiés dans la sous-section « Display ». Pour chaque mode choisi, la ligne de mode correspondante à la résolution de ce mode est utilisée pour générer les signaux à destination du moniteur.

Note : La résolution virtuelle de l'écran n'est pas modifiée lorsqu'on change de résolution physique. Elle est toujours égale à la plus grande des résolutions disponibles dans la section « Display » utilisée. Seule la résolution physique de l'affichage est modifiée. Vous pourrez déplacer la zone d'affichage en déplaçant la souris, et faire défiler ainsi tout l'écran.

Il est impossible de changer la profondeur de couleur utilisée sans redémarrer le serveur X. Les seuls changements acceptés sont ceux concernant les résolutions graphiques listées dans la sous-section « Display » pour la profondeur de couleur courante.

X-C-6. Utilisation de xvidtune▲

xvidtune est un petit utilitaire permettant de régler les paramètres d'affichage de chaque mode graphique. Grâce à lui, vous pourrez ajuster la taille de l'image horizontalement et verticalement, ainsi que sa position par rapport aux bords du moniteur. xvidtune se lance simplement, en tapant son nom en ligne de commande :

Sélectionnez

xvidtune

Dès qu'il démarre, il commence par afficher une fenêtre d'avertissement, pour vous prévenir qu'un usage par une personne non avertie peut provoquer de sérieux dommages au moniteur. En effet, il permet de modifier les paramètres de synchronisation horizontale et verticale du moniteur pour ajuster l'image. Si vous choisissez de mauvais paramètres, vous pouvez sortir des spécifications techniques de votre moniteur, ce qui pourrait fort bien l'endommager. Fort heureusement, la plupart des moniteurs modernes disposent de mécanismes de sécurité qui les empêchent de générer l'image lorsque ces paramètres sont incorrects. Par conséquent, il est assez rare d'avoir des problèmes avec cet utilitaire, d'autant plus qu'il effectue des contrôles avant toute tentative douteuse. Vous pouvez donc valider en toute confiance, mais soyez malgré tout averti des risques potentiels. Rappelons que le serveur X peut être arrêté à n'importe quel moment à l'aide de la séquence de touches CTRL+ALT+BACKSPACE.

L'écran de xvidtune se compose de quatre parties. La partie supérieure gauche permet de régler les paramètres horizontaux du mode graphique, à savoir la largeur de l'image et sa position par rapport aux bords verticaux du moniteur. La partie supérieure droite permet de régler les paramètres verticaux, à savoir la hauteur et la position par rapport aux bords horizontaux du moniteur. La partie inférieure droite contient les informations essentielles sur le mode vidéo courant. Enfin, la partie inférieure gauche contient les boutons permettant de choisir les actions à effectuer.

Les paramétrages horizontaux et verticaux du mode graphique peuvent être modifiés très simplement. Les boutons « Left » et « Right » permettent de centrer l'image horizontalement, et les boutons « Wider » et « Narrower » permettent d'ajuster sa largeur. De même, les boutons « Up » et « Down » influent sur le centrage vertical, et les boutons « Shorter » et « Taller » ajustent sa hauteur.

Vous pouvez tester les modifications apportées à tout instant à l'aide du bouton « Test ». Il est même recommandé d'essayer régulièrement les paramètres choisis et de procéder pas à pas. Lorsque les paramètres conviennent, ils peuvent être appliqués immédiatement à l'aide du bouton « Apply ». Si vous désirez générer une ligne mode valide pour la configuration courante, par exemple afin de modifier votre fichier de configuration xorg.conf, vous pouvez cliquer sur le bouton « Show ». La ligne de mode sera affichée sur le terminal à partir duquel vous avez lancé xvidtune. Vous pourrez alors la recopier dans le fichier xorg.conf à la place de la ligne de mode du mode graphique en cours d'utilisation.

Il est possible de changer le mode graphique courant en cliquant sur les boutons « Next » et « Prev ». Ils permettent de passer en revue tous les modes graphiques qui ont été enregistrés dans le fichier xorg.conf par xorgconfig ou xorgcfg. Une fois que vous aurez ajusté tous les modes graphiques et que vous les aurez enregistrés à l'aide du bouton « Apply », vous pourrez quitter xvidtune en cliquant sur le bouton « Quit ». Notez que le bouton « Apply » valide les choix en cours, mais ne les enregistre pas dans le fichier xorg.conf. Vous devez reporter manuellement dans le fichier xorg.conf les paramètres du mode courant, tels qu'ils sont présentés par la commande « Show ».

X-D. Utilisation du pilote frame buffer du noyau▲

Si par malheur votre carte graphique n'est gérée par aucun des pilotes de X.org (cas relativement exceptionnel), vous serez sans doute obligé d'utiliser le pilote vesa. Ce pilote permet d'utiliser toutes les cartes compatibles avec le standard VESA 2.0 (c'est-à-dire la plupart des cartes graphiques, mais il existe des exceptions notables).

Il existe une alternative à ce pilote, qui se base sur les fonctionnalités « frame buffer » du noyau de Linux. Cette fonctionnalité permet d'utiliser Linux complètement en mode graphique, en fournissant un accès linéaire direct à la mémoire vidéo de la carte graphique grâce au fichier spécial de périphérique /dev/fb0. Il existe un pilote X.org pour le frame buffer du noyau, qui permet donc de démarrer le serveur X en s'appuyant complètement sur le noyau. L'avantage du frame buffer du noyau est que même les consoles en mode texte feront leur affichage en mode graphique (cela est aussi un inconvénient du point de vue des performances). En revanche, vous ne pourrez pas changer de résolution une fois que le système aura démarré.

Pour accéder à la mémoire vidéo, le noyau se base également sur l'interface de programmation du standard VESA 2.0, qui est gérée par le BIOS de la plupart des cartes graphiques récentes. Cela signifie également que vous ne disposerez pas d'accélération matérielle en général, sauf pour quelques cartes graphiques courantes reconnues par le noyau.

X-D-1. Configuration du noyau et installation du pilote▲

La mise en œuvre du pilote pour le frame buffer se fait évidemment dans la configuration du noyau. Les options à activer sont toutes dans le menu « Console drivers ». En plus de l'option « VGA text console », vous devez impérativement activer « Video mode selection support ». Cette option vous permettra de choisir le mode VESA à utiliser lors du démarrage de l'ordinateur. Vous devrez également cocher l'option « Support for frame buffer devices (EXPERIMENTAL) » (cette option ne vous sera proposée que si vous avez validé l'option « Prompt for development and/or incomplete code/drivers » du menu « Code maturity level options »). Les options suivantes du gestionnaire du frame buffer du noyau devront également être activées :

« VESA VGA graphics console » (cette option permet d'utiliser un mode graphique VESA indiqué au démarrage pour l'affichage de la console) ;
« Advanced low level driver options (NEW) » (cette option vous permet de préciser la structure de la mémoire vidéo dans les différents modes graphiques utilisés avec le frame buffer) ;
« 8 bpp packed pixels support », « 16 bpp packed pixels support », « 24 bpp packed pixels support » et « 32 bpp packed pixels support » (ces options correspondent aux différentes structures de la mémoire vidéo qui sont utilisées par les modes graphiques VESA) ;
« Select compiled-in fonts (NEW) » (cette option vous permet de choisir les polices de caractères qui seront utilisées par la console) ;
« VGA 8x8 font » et « VGA 8x16 font » (ces deux polices sont les polices standards utilisées par la console).

Il faut ensuite vérifier que le fichier spécial de périphérique /dev/fb0 a été créé par le programme d'installation de votre distribution. Si ce n'est pas le cas, vous devez le créer à l'aide de la commande mknod. Le numéro de périphérique majeur de ce fichier est 29. Le numéro mineur à utiliser est le numéro du périphérique. Par exemple, le fichier spécial de périphérique /dev/fb0 porte les numéros 29 et 0, le fichier /dev/fb1 porte les numéros 29 et 1, etc. Ces fichiers sont tous de type caractère, la ligne de commande pour créer un de ces fichiers est donc la suivante :

Sélectionnez

mknod fbn c 29 n

où n est le numéro du fichier spécial de périphérique à créer.

Il est également recommandé de créer un lien symbolique /dev/fb vers /dev/fb0 afin d'assurer la compatibilité avec de vieux programmes utilisant ce nom pour accéder au fichier spécial de périphérique du gestionnaire du frame buffer du noyau.

Une fois ces opérations réalisées, vous devez compiler le noyau et l'installer, en suivant la méthode décrite dans la partie décrivant la compilation du noyau. Lors du redémarrage du système, vous pourrez passer l'option suivante au noyau pour préciser le mode graphique VESA à utiliser :

Sélectionnez

vga=mode

où mode est le numéro du mode graphique désiré. Les numéros valides sont indiqués dans le tableau donné ci-dessous :

Tableau 10-2. Numéros des modes graphiques VESA

Couleurs	Résolution
	640x480	800x600	1024x768	1280x1024	1600x1200
256	769	771	773	775	796
32768	784	787	790	793	797
65536	785	788	791	794	798
16,8M	786	789	792	795	799

Si tout se passe correctement, votre système devrait démarrer dans le mode graphique indiqué et afficher le logo de Linux (un pingouin nommé « Tux », pour ceux qui ne le sauraient pas encore). Lorsque vous aurez déterminé le mode graphique qui vous convient, vous pourrez modifier le fichier de configuration de Lilo et spécifier le numéro de ce mode dans la ligne « vga=… ». De cette manière, votre système redémarrera automatiquement dans ce mode graphique.

X-D-2. Configuration du serveur X▲

Les manipulations précédentes n'ont pas grand intérêt si vous ne désirez travailler qu'avec la console. En effet, l'affichage en mode graphique est beaucoup plus lent que l'affichage en mode texte, et l'affichage du pingouin Tux au démarrage ne vous apportera pas grand-chose. C'est pour cela que l'étape suivante est normalement de configurer le serveur X de X.org pour le pilote frame buffer, afin d'utiliser l'environnement graphique XWindow et son système de fenêtrage.

La configuration du serveur X est élémentaire. Il faut avant tout s'assurer que l'on dispose bien du pilote permettant au serveur X d'utiliser l'interface /dev/fb0. Ce pilote se nomme fbdev, et utilise un autre module spécifique au système d'exploitation nommé fbdevhw. Il faut ensuite modifier ou créer le fichier xorg.conf pour utiliser ce pilote. Les seules sections à modifier pour utiliser le pilote frame buffer sont la section « Device » et la section « Screen ».

La section « Device » est réduite à sa plus simple expression, puisque tous les paramètres sont fixés par le mode VESA choisi au démarrage d'une part, et parce que le serveur X ne saurait pas les exploiter d'autre part. Il suffit donc d'indiquer que le pilote à utiliser est le pilote fbdev, et de donner l'adresse de la carte vidéo sur le bus à l'aide du mot-clef « BusID » :

Sélectionnez

Section "Device"
    Identifier "Carte 1"
    Driver "fbdev"
    BusID  "PCI:1:5:0"
EndSection

Vous pourrez déterminer l'adresse de votre carte graphique à l'aide de la commande lspci, ou en demandant au serveur X de scanner les bus PCI en lui passant l'option -scanpci en paramètre :

Sélectionnez

X.org -scanpci

La section « Screen » est elle aussi très simplifiée, puisque le seul mode graphique utilisable est le mode choisi au démarrage de la machine. La liste des modes utilisables peut donc être franchement omise, ou se réduire à la valeur spéciale « default » :

Sélectionnez

Section "Screen"
    Device    "Carte 1"
    Monitor   "Moniteur 1"
    DefaultDepth 16
    SubSection "Display"
        Depth 16
        Modes "default"
    EndSubSection
EndSection

Notez qu'il est impératif que la profondeur de couleur de la sous-section « Display » soit la même que celle du mode VESA indiqué au démarrage. Prenez garde à ne pas utiliser une profondeur de couleur trop élevée, car cela dégraderait encore un peu plus les performances. Par ailleurs, comme aucun mode n'est spécifié dans la section « Screen », les lignes de mode des sections « Monitor » sont à présent facultatives. Ces sections peuvent donc être simplifiées également.

Une fois ces modifications réalisées, vous devrez pouvoir démarrer XWindow simplement avec la commande startx. Vous disposerez alors de toutes les fonctionnalités de XWindow, avec des performances quelque peu inférieures à celles que vous auriez avec un serveur X adapté à votre carte graphique. Il est conseillé de suivre l'actualité de X.org afin de savoir si un tel serveur est en cours de développement et, si oui, d'en récupérer une version finale dès que possible.

X-E. Configuration des terminaux X▲

Nous avons vu dans le chapitre de configuration du système de base que la connexion des utilisateurs se faisait par l'intermédiaire d'un terminal. La plupart des terminaux sont en mode texte, mais il est également possible d'utiliser des terminaux graphiques sous XWindow. Les terminaux de ce type sont logiquement appelés « terminaux X ».

Si le niveau d'exécution par défaut de votre système est le niveau associé au démarrage sous XWindow (ce niveau est en général 3, 4 ou 5 selon les distributions), XWindow est lancé dès le démarrage de la machine et la demande de connexion se fait via un écran graphique. Dans ce cas, vous vous connecterez directement par l'intermédiaire de ce terminal X. Le principe de fonctionnement des terminaux X n'est pas exactement le même que celui que nous avons vu pour les terminaux virtuels (voir la Section 6.8). En effet, les terminaux X ne sont pas gérés par les processus getty et login classiques, mais par un programme spécifique nommé « xdm » (abréviation de l'anglais « X Display Manager »).

X-E-1. Principe de fonctionnement de xdm▲

Contrairement à ce qu'il fait avec les processus getty, init ne lance qu'un script d'initialisation de XWindow lorsqu'il passe dans le niveau d'exécution correspondant. Ce script a pour tâche essentiellement le démarrage du démon xdm. C'est ce démon qui est en charge de gérer les connexions sur tous les serveurs X qu'il peut trouver, en proposant la fenêtre de login et en permettant ainsi à l'utilisateur de s'identifier et s'authentifier.

En général, xdm lance lui-même le serveur X de la machine locale, et surveille son exécution. Lorsque l'utilisateur se déconnecte, le serveur X se réinitialise, et xdm affiche une nouvelle fenêtre de connexion. Cependant, xdm est également capable d'utiliser des serveurs X distants (qui sont donc déjà lancés), afin de permettre la connexion d'utilisateurs sur des terminaux X déportés. Enfin, il est possible de le configurer pour qu'il se signale sur un réseau, afin que les serveurs X fonctionnant sur ce réseau puissent lui demander une connexion. Les serveurs X capables de se connecter à xdm de cette manière doivent comprendre le protocole XDMCP (abréviation de l'anglais « XDM Control Protocol »). Comme on le voit, la souplesse de ce mécanisme est tout simplement exceptionnelle.

Note : Pratiquement, le processus xdm se duplique pour chaque terminal X dont il gère la connexion. Ainsi, chaque processus xdm propose la connexion et surveille la déconnexion de l'utilisateur sur un terminal X donné. Tous les processus xdm sont lancés par le processus xdm initial qui a été lancé par les scripts de changement de niveau d'exécution. Ce mécanisme est donc complètement transparent pour l'utilisateur.

La plupart des environnements graphiques modernes (comme KDE et GNOME) fournissent leur propre gestionnaire de display. Ces gestionnaires sont toutefois compatibles avec xdm, et leur configuration se fait de la même manière.

X-E-2. Configuration de xdm▲

Le comportement de xdm est complètement défini dans ses fichiers de configuration, qui sont en général placés dans le répertoire /etc/X11/xdm/. Ces fichiers de configuration décrivent chacun un des aspects du comportement de xdm. Le fichier de configuration principal est le fichier xdm-config, qui contient les références sur les autres fichiers de configuration. Notez que si vous utilisez l'environnement de bureau KDE et son gestionnaire de connexion kdm, les fichiers de configuration à utiliser sont ceux de kdm. Bien qu'ils soient strictement compatibles avec ceux de xdm, ces fichiers se situent dans le répertoire de configuration de kdm. Ce répertoire est généralement le sous-répertoire share/config/kdm/ du répertoire d'installation de KDE.

X-E-2-a. Serveurs X locaux▲

La définition des serveurs X qui n'utilisent pas le protocole XDMCP et que xdm doit prendre en charge directement est réalisée dans le fichier de configuration référencé par la ligne « DisplayManager.servers » du fichier xdm-config. Par défaut, ce fichier est le fichier /etc/X11/xdm/Xservers. Il contient une ligne par serveur, chaque ligne ayant la syntaxe suivante :

Sélectionnez

display type [commande]

où display est le nom du display à utiliser, type est le type de serveur X (serveur local ou distant), et commande est la commande à exécuter pour lancer le serveur s'il est local. Le display indiqué sera celui qui sera utilisé pour définir la variable d'environnement DISPLAY, et doit donc utiliser la syntaxe normale des displays. Les deux types de serveurs disponibles sont « local », pour les serveurs de la machine locale que xdm doit lancer lui-même, et « foreign », pour les serveurs distants sur lesquels xdm doit afficher la fenêtre de demande de connexion (ils doivent donc être déjà lancés). La ligne de commande à utiliser pour le lancement du serveur ne doit être spécifiée que pour les serveurs de type « local ».

Les serveurs X peuvent prendre un certain nombre de paramètres en ligne de commande pour leur démarrage. Vous en trouverez la liste complète dans la page de manuel Xserver et dans la page de manuel X.org. Les options les plus intéressantes dans le cadre du lancement du serveur X par xdm sont celles permettant de définir le display que le serveur aura en charge et le terminal virtuel qu'il devra utiliser pour effectuer son affichage. Notez bien que le display doit être le même que celui donné à xdm. Ces deux options sont passées directement à la suite du nom de l'exécutable du serveur X à lancer :

Sélectionnez

/usr/bin/X display vtNN

où vtNN est le nom du terminal virtuel à utiliser (vt01 pour /dev/tty01, vt02 pour /dev/tty02, etc.).

Ainsi, si l'on veut faire en sorte que xdm lance automatiquement deux sessions X sur les terminaux virtuels 11 et 12, en leur affectant respectivement les displays :0.0 et :1.0, on devra placer ces deux lignes dans son fichier de configuration Xservers :

Sélectionnez

:0 local /usr/bin/X :0 vt11
:1 local /usr/bin/X :1 vt12

Note : La spécification du terminal virtuel à utiliser est facultative. Si aucun terminal n'est indiqué, le serveur X utilisera le premier terminal qu'il trouvera. Cependant, il est plus sûr de toujours indiquer le terminal à utiliser, car le noyau ne crée les terminaux qu'à la demande, lorsqu'un processus désire y accéder. Or les serveurs X ne cherchent pas à en créer de nouveau. Si tous les terminaux virtuels existants sont déjà utilisés, le serveur X tentera donc de s'en approprier un, sans se préoccuper du programme qui l'utilise à ce moment. Le fait d'indiquer manuellement le terminal à utiliser vous évitera donc des problèmes assez curieux, tels que ceux qui peuvent survenir si les terminaux utilisés par les serveurs X le sont déjà par un getty par exemple. De plus, cela permet également d'éviter, si on lance plusieurs serveurs X sur la même machine, qu'ils n'accèdent ensemble au même terminal virtuel lors de leur initialisation.

Il est recommandé par ailleurs de basculer sur chaque terminal virtuel sur lequel un serveur X est lancé avant de se connecter afin de les forcer à créer leur terminal. En effet, si vous ne procédez pas ainsi, il est possible que vous ayez le temps de vous connecter dans une session X avant que les autres terminaux X n'aient fini de s'initialiser. Lorsque ceux-ci démarreront, ils changeront le terminal virtuel courant et l'affichage de votre bureau risque d'être corrompu. Si cela se produit, ne vous inquiétez pas : votre session X n'a pas planté. Assurez-vous seulement que vous vous trouvez bien sur le bon terminal virtuel, et faites en sorte que l'écran soit rafraîchi (par exemple, changez de bureau virtuel ou déplacez une fenêtre sur l'écran).

Remarquez également que les fichiers de configuration fournis avec X.org ne prévoient pas l'utilisation de plus de deux sessions X par défaut. Si d'aventure vous désirez en utiliser plus, vous devrez compléter le fichier de configuration xdm-config avec les lignes suivantes :

Sélectionnez

DisplayManager._2.authorize:    true
DisplayManager._3.authorize:    true
etc.

Chaque ligne indique que le display correspondant (:2 pour « DisplayManager._2.authorize », etc.) doit utiliser les mécanismes de sécurité de XWindow. Nous verrons ces mécanismes dans la section suivante.

Méfiez-vous enfin de la consommation mémoire requise par chaque session X. Les serveurs X sont des programmes gourmands en mémoire, car ils doivent manipuler des images. Les performances du système risquent donc de se dégrader sensiblement si vous lancez plusieurs serveurs X. N'oubliez pas qu'après tout, XWindow est un système de fenêtrage et que la plupart des gestionnaires de fenêtres X donnent la possibilité d'utiliser des bureaux virtuels. En pratique, deux sessions X devraient suffire, afin de se connecter sous deux utilisateurs différents (un utilisateur normal et l'utilisateur root par exemple).

Enfin, notez que le changement d'un terminal X à un autre terminal virtuel peut provoquer quelques problèmes en ce qui concerne l'état du clavier. En effet, l'affichage des diodes (Verrou numérique et Majuscule en particulier) n'est pas rétabli correctement, même si le clavier continue à fonctionner correctement. Cela peut surprendre quelque peu la première fois que l'on rencontre ce problème. Il suffit d'appuyer deux fois de suite sur les touches Verr Num et Caps Lock (c'est-à-dire la touche de verrouillage des majuscules) afin de rétablir l'état correct de ces diodes. Remarquez également que les serveurs X mémorisent l'état des terminaux virtuels lors de leur démarrage, et neutralisent à chaque basculement vers un terminal en mode texte les éventuels changements de police de caractères.

X-E-2-b. Serveurs X utilisant XDMCP▲

Comme nous l'avons dit plus haut, xdm est également capable de se signaler sur un réseau à l'aide du protocole XDMCP, afin de permettre aux serveurs X distants de réaliser une connexion sur la machine où il est lancé. De cette manière, le lancement d'un serveur X sur une machine du réseau permettra d'obtenir la fenêtre de connexion à votre machine Linux.

xdm est capable de répondre aux demandes de connexion directe des serveurs X distants (remarquez que dans ce cas, xdm est serveur de connexions pour les serveurs X des postes clients. Faites bien attention à la terminologie client/serveur ici !). Cela suppose que chaque poste client connaisse l'adresse des machines qui utilisent xdm. Cette information peut faire partie de la configuration du poste client, mais elle peut également être déterminée dynamiquement. Pour cela, le serveur X du poste client émet une requête XDMCP en mode broadcast sur le réseau (c'est-à-dire à destination de tout le monde). Chaque machine sur laquelle xdm fonctionne répondra à ce client, et le serveur X proposera ainsi la liste des machines sur lesquelles une connexion est réalisable via xdm. Ainsi, l'utilisateur du poste client pourra choisir le serveur sur lequel il désire se connecter, et le processus xdm de ce serveur lui enverra la fenêtre de login.

En réalité, tous les serveurs X ne sont pas capables de gérer les réponses reçues de plusieurs processus xdm provenant de plusieurs machines à la suite de l'envoi d'une requête en mode broadcast. Par ailleurs, il n'est pas toujours possible d'utiliser le mode broadcast, car les paquets de ce type peuvent très bien ne pas être routés lors de la traversée d'une passerelle. Par conséquent, xdm offre également la possibilité d'interroger les machines du réseau local en réponse à une requête de connexion indirecte. Le serveur X reçoit en réponse le résultat de la requête effectuée par broadcast, et l'utilisateur peut choisir la machine à laquelle il désire accéder.

La configuration de xdm pour le protocole XDMCP se fait dans le fichier identifié par la ligne « DisplayManager.accessFile » du fichier xdm-config. Par défaut, le fichier ainsi référencé est le fichier Xaccess du répertoire /etc/X11/xdm/. La syntaxe de ce fichier est très simple. Il contient des règles indiquant le comportement de xdm lorsqu'il reçoit une requête de connexion de la part d'un serveur X. Ces règles sont définies pour des groupes de machines. Les machines sont identifiées par leur nom ou leur adresse IP, plusieurs machines pouvant être spécifiées par une même règle grâce aux caractères génériques classiques '*' et '?'. Il est également possible d'exclure une machine ou un groupe de machines en préfixant le nom du caractère de négation '!'.

Il existe quatre types de lignes dans le fichier Xaccess. Le premier type permet simplement d'indiquer que les connexions directes ou en mode broadcast provenant d'une machine sont toutes acceptées. Ce sont les lignes les plus simples, puisqu'il suffit d'indiquer la machine ou le groupe de machines. Par exemple, la ligne suivante :

Sélectionnez

*.localnet.org

indique que les demandes de connexion provenant de toutes les machines du domaine « localnet.org » sont acceptées. Il est possible de faire en sorte que xdm ne réponde qu'aux demandes de connexion directes simplement en ajoutant le mot clé « NOBROADCAST » à la suite de la ligne. Ainsi, si la machine « termX3.localnet.org » doit pouvoir se connecter directement, mais ne doit pas recevoir de réponse de notre machine, on ajoutera la ligne suivante dans le fichier Xaccess :

Sélectionnez

termX3.localnet.org NOBROADCAST

Le deuxième type de ligne permet de spécifier le comportement de xdm pour les demandes de connexion indirectes. Ces lignes contiennent toujours le nom de la machine ou du groupe de machines, mais ce nom est suivi de la liste des machines auxquelles xdm doit faire suivre la demande de connexion du serveur X. Par exemple, supposons que la machine « termX2.localnet.org » ne soit pas capable d'effectuer des requêtes en mode broadcast, et que l'on veuille qu'elle puisse se connecter sur les serveurs « s5.localnet.org », « s11.localnet.org » et « s13.localnet.org ». On devra alors ajouter la ligne suivante dans le fichier Xaccess :

Sélectionnez

termX2.localnet.org   s5.localnet.org s11.localnet.org \
    s13.localnet.org

Le troisième type de ligne permet de lancer un programme nommé « chooser » et qui va proposer la liste des serveurs à l'utilisateur du serveur X qui demande à se connecter. Ce programme est très utile pour les serveurs X qui ne sont pas capables de proposer ce choix à l'utilisateur. La syntaxe de ces lignes est très simple, puisqu'il suffit de faire précéder les noms des serveurs par le mot clé CHOOSER. Si l'on reprend l'exemple précédent, la ligne de configuration pour le terminal X « termX2 » deviendrait :

Sélectionnez

termX2.localnet.org   CHOOSER s5.localnet.org s11.localnet.org s13.localnet.org

La liste des serveurs qui suit peut être assez longue, et il peut être utile de faire en sorte que le programme chooser effectue une requête en mode broadcast pour le compte du serveur X qui n'en est pas capable. Il suffit pour cela de remplacer la liste des serveurs par le mot clé « BROADCAST ». Ainsi, la ligne suivante :

Sélectionnez

termX4.localnet.org   CHOOSER BROADCAST

signifie simplement que lorsque le serveur X de la machine « termX4.localnet.org » se connecte au processus xdm local, celui-ci lance le programme chooser. Ce dernier lance une requête en broadcast sur le réseau afin de déterminer la liste des machines exécutant le processus xdm. Une fois qu'il a obtenu cette liste, il l'affiche sur le display géré par le serveur X qui s'est connecté. De cette manière, l'utilisateur peut choisir la machine sur laquelle il va se connecter. Le serveur X est mis en relation avec le processus xdm de cette machine, et la fenêtre de login est enfin proposée à l'utilisateur.

Le quatrième type de ligne permet de définir des « macros » de remplacement pour gérer les listes de noms de machines plus simplement. La définition d'une macro se fait avec la syntaxe suivante :

Sélectionnez

%nom    liste

où nom est le nom de la macro à définir, et liste est la liste des machines qu'elle représente. Il est possible d'utiliser des macros dans les définitions de macros.

Note : Le protocole XDMCP utilise le port 117 du protocole UDP. Vous pourrez donc ajouter la ligne suivante dans votre fichier /etc/services, si elle ne s'y trouve pas déjà :

Sélectionnez

xdmcp    117/udp

Notez également que vous ne pourrez pas tester votre configuration en utilisant l'interface réseau loopback. En effet, xdm vérifie la validité des adresses sources des paquets qu'il reçoit, et il refuse par défaut tout paquet provenant de l'adresse 127.0.0.1. Si vous désirez malgré tout utiliser XDMCP sans réseau réel, vous pourrez utiliser l'interface réseau dummy. Cette interface peut être créée en activant l'option « Dummy net driver support » du menu « Network device support ».

X-E-2-c. Paramétrage du serveur X pour utiliser le protocole XDMCP▲

L'écriture du fichier Xaccess ne représente que la partie serveur du travail de configuration du protocole XDMCP. En effet, il faut encore indiquer aux serveurs X distants à quel processus xdm il doivent tenter de se connecter lors de leur démarrage. Bien entendu, cela dépend fortement du serveur X utilisé, qui peut être quelconque. Par exemple, le serveur X peut très bien fonctionner sur une machine Windows. Par conséquent, seule la syntaxe des serveurs de X.org sera décrite ici.

Les serveurs X de X.org utilisent des options en ligne de commande pour déterminer comment ils doivent se comporter à leur démarrage. Lorsqu'ils sont lancés directement par xdm (c'est-à-dire lorsqu'ils sont lancés en local, avec les options indiquées dans le fichier Xservers), ils n'ont pas besoin d'options spécifiques, car ils n'utilisent pas XDMCP dans ce cas. En revanche, si l'on désire les lancer manuellement (ou dans un script d'initialisation), on devra utiliser l'une des options suivantes :

-query permet de demander une connexion directe sur une machine donnée. Le nom de la machine doit être spécifié à la suite de l'option ;
-indirect permet de demander une connexion indirecte sur une machine donnée. Le nom de cette machine doit être spécifié à la suite de l'option. La liste des machines qui a été indiquée dans le fichier Xaccess sera retournée, ou bien le programme chooser sera lancé ;
-broadcast permet de demander au serveur X d'effectuer une requête de connexion en broadcast sur le réseau.

Les serveurs de X.org ne sont pas capables de proposer une liste de machines à l'utilisateur. Ils prennent systématiquement la première machine qu'ils trouvent. Vous ne contrôlerez donc pas la machine sur laquelle la connexion sera faite si vous utilisez l'option -broadcast. C'est pour cela qu'il est recommandé d'utiliser le programme chooser dans le fichier de configuration Xaccess et de configurer les serveurs pour faire des demandes de connexion indirectes.

X-E-2-d. Fichiers d'initialisation de sessions▲

xdm fournit la possibilité d'effectuer des actions lorsque divers événements concernant la session XWindow en cours ont lieu. Par exemple, il est possible de réaliser un traitement particulier pour l'initialisation de l'environnement d'un serveur X, pour fixer l'environnement de l'utilisateur qui se connecte, et pour effectuer le ménage lorsqu'il ferme sa session. Toutes ces actions sont effectuées dans des scripts qui sont référencés par des lignes du fichier xdm-config.

La ligne « DisplayManager.DISPLAY.setup », où DISPLAY est le nom du display (_0 pour :0, _1 pour :1, etc.), référence un script qui est exécuté au nom de l'utilisateur root avant que la fenêtre de login ne soit présentée. Le fichier par défaut utilisé par X.org est le fichier /etc/X11/xdm/Xsetup. C'est donc dans ce script que vous pourrez mettre des commandes d'initialisation spécifiques pour préparer le login.

De la même manière, la ligne « DisplayManager.DISPLAY.startup » référence le script Xstartup par défaut. Ce fichier est exécuté sous le compte root juste après l'authentification de l'utilisateur. C'est ici que l'on pourra par exemple enregistrer la connexion de l'utilisateur dans le système.

La ligne « DisplayManager.DISPLAY.session » référence quant à elle le script Xsession, qui est exécuté après Xstartup, mais au nom de l'utilisateur cette fois. Ce script prend généralement en charge le lancement des programmes nécessaires à la gestion de la session de l'utilisateur. Par exemple, il est possible d'y placer les commandes de lancement du gestionnaire de fenêtres ou du gestionnaire de bureau.

Enfin, la ligne « DisplayManager.DISPLAY.reset » référence le script Xreset du répertoire /etc/X11/xdm/, qui est exécuté au nom de l'utilisateur root lorsque la session X se termine. Vous pouvez donc exécuter les tâches nécessaires pour faire le ménage à cet endroit, par exemple le désenregistrement de la connexion de l'utilisateur dans le système.

Tous ces scripts sont lancés sans paramètres, sauf le script Xsession. Ce script peut en effet recevoir des paramètres fournis par le gestionnaire de connexions (xdm, kdm, gdm ou autre), qui permettent de représenter les choix que l'utilisateur a faits pour sa connexion dans la fenêtre de login. Le premier paramètre de ce script est normalement le nom du gestionnaire de fenêtres à utiliser. Par exemple, pour l'environnement de bureau KDE, le programme qui doit être exécuté est le script startkde, alors que pour l'environnement de bureau Gnome, il s'agit du programme gnome-session. Notez que le nom « failsafe » référence un mode dégradé, et n'est normalement utilisé que quand les autres gestionnaires de fenêtres disponibles ne se lancent pas correctement.

Les scripts lancés au nom de l'utilisateur root (Xsetup et Xreset) sont exécutés dans un environnement minimal. La valeur de la variable d'environnement PATH pour ces scripts est déterminée par la valeur de la ligne « DisplayManager.DISPLAY.systemPath » du fichier de configuration xdm-config. De même, le script Xsession est exécuté avec la variable d'environnement PATH fixée à la valeur spécifiée par la ligne « DisplayManager.DISPLAY.userPath » du fichier xdm-config. Si vos scripts de gestion des connexions ne fonctionnent pas correctement, c'est sans doute un problème lié à l'environnement.

En pratique, ces fichiers de scripts de gestion des connexions sont fournis par votre distribution et vous ne devriez donc pas à avoir à y toucher. Vous pouvez toutefois y faire quelques modifications si vous estimez que les actions effectuées ne vous conviennent pas. En particulier, certaines distributions n'enregistrent pas l'utilisateur qui commence une nouvelle session. Cette opération est nécessaire, parce que xdm n'est pas un processus de login classique et ne le fait pas automatiquement (il n'utilise pas de terminal pour faire la connexion). Vous aurez pour cela à utiliser l'utilitaire sessreg fourni avec XWindow. Cet utilitaire permet d'enregistrer un utilisateur avec l'option -a et de le supprimer avec l'option -d. Vous devrez donc typiquement placer une ligne telle que celle-ci :

Sélectionnez

sessreg -a -l $DISPLAY -x /etc/X11/xdm/Xservers $LOGNAME

dans le fichier Xstartup, afin d'enregistrer les utilisateurs qui commencent une session XWindow, et une autre ligne telle que celle-ci :

Sélectionnez

sessreg -d -l $DISPLAY -x /etc/X11/xdm/Xservers $LOGNAME

dans le fichier Xreset, afin de les supprimer lorsqu'ils terminent cette session.

X-E-3. Paramétrage des terminaux X▲

La configuration des terminaux X comprend un certain nombre de points qui vont de l'ajustement du nombre de couleurs et de la résolution à la disposition du clavier, en passant par les paramètres de la souris et l'économiseur d'écran. Heureusement, nous avons déjà vu comment nous pouvions contrôler un grand nombre de ces paramètres. Par exemple, la résolution graphique, ainsi que le nombre de couleurs et la disposition du clavier, sont définis dans le fichier de configuration général de X.org xorg.conf. Nous verrons donc ici comment modifier des paramètres qui tiennent plus de l'ergonomie que de la configuration de base.

X-E-3-a. La commande xset▲

Ces paramètres peuvent souvent être fixés lors du démarrage du serveur X, ou dynamiquement avec la commande xset. Les paramètres que l'on peut fixer avec xset sont très nombreux, et seuls les plus utiles seront décrits ici. Veuillez consulter la page de manuel xset pour plus de détails.

L'option dpms permet de fixer les temps d'attente avant la mise en veille du moniteur. Sachez que la mise en veille constitue de loin le meilleur économiseur d'écran, et que les économiseurs logiciels du type ballet de lignes sont très jolis, mais ne servent à rien. Pire, ils peuvent ralentir la machine, ce qui est inadmissible si vous l'utilisez en tant que serveur (heureusement, les économiseurs d'écran logiciels se lancent généralement avec des priorités très faibles, afin de ne pas perturber les autres processus).

Cette option prend de un à trois paramètres, qui représentent respectivement le temps avant le passage en mode économie d'énergie du moniteur, le temps avant le passage en mode veille, et le temps avant l'extinction complète du moniteur. Ces temps sont exprimés en secondes, la valeur nulle permettant de désactiver cette fonctionnalité. Ainsi, la commande suivante :

Sélectionnez

xset dpms 0 0 600

permet d'éteindre l'écran au bout de dix minutes d'inactivité.

Ces temps peuvent également être fixés dans le fichier de configuration xorg.conf, où ils sont exprimés en minutes, à l'aide des mots clés « StandbyTime », « SuspendTime » et « OffTime ». Ces mots clés doivent être placés dans la section « ServerFlags » du fichier de configuration. Cependant, les serveurs X n'activent ces fonctionnalités que pour les moniteurs capables de gérer le standard DPMS. Ces moniteurs doivent donc être signalés à l'aide de la ligne suivante :

Sélectionnez

    Option "DPMS" "On"

dans la section « Monitor » qui les définit.

Note : Les valeurs des temps d'attente que vous pouvez fixer dans le fichier de configuration xorg.conf peuvent être écrasées par les valeurs définies dans la configuration de votre gestionnaire de bureau. Vous devrez donc vérifier ces paramètres si les modifications que vous faites dans le fichier xorg.conf ne sont pas prises en compte ou si l'économie d'énergie reste désactivée malgré la présence de l'option DPMS dans la section « Monitor » de votre moniteur.

Une autre option importante de la commande xset est l'option fp, qui permet d'ajouter et de supprimer des chemins de répertoires de polices de caractères. Pour ajouter un répertoire, il suffit d'utiliser l'option +fp et de faire suivre le chemin de ce répertoire. La suppression d'un répertoire se fait de la même manière, avec l'option -fp. Par exemple, pour ajouter le répertoire de polices /usr/share/fonts/100dpi/ à la liste des répertoires de polices du serveur, il suffit de taper la commande suivante :

Sélectionnez

xset +fp /usr/share/fonts/100dpi

De plus, comme nous l'avons déjà vu plus haut, les chemins des répertoires de polices de caractères peuvent être fixés statiquement à l'aide du mot clé « FontPath » de la section « Files » du fichier de configuration xorg.conf.

Enfin, l'option q de xset vous permettra de visualiser l'ensemble des paramètres en cours d'utilisation.

X-E-3-b. Configuration de la disposition du clavier▲

Nous avons vu dans le chapitre de configuration du système de base le fonctionnement du clavier sous Linux. Les applications qui lisent les données provenant du pilote clavier de la console peuvent travailler au niveau ASCII, au niveau keycode ou au niveau scancode. Les serveurs X font partie des logiciels qui préfèrent la troisième solution, ce qui signifie qu'ils interprètent eux-mêmes le flux de scancodes provenant du clavier.

La raison de ce choix est que X.org est une implémentation portable du système XWindow pour PC. Cela signifie qu'il est prévu pour fonctionner sur plusieurs systèmes d'exploitation de type Unix et fonctionnant sur l'architecture compatible PC. Par conséquent, il ne pouvait pas se baser sur des keycodes, qui sont évidemment dépendants du système utilisé.

L'inconvénient en revanche est que cela impose que les serveurs X définissent un mécanisme parallèle de gestion des touches du clavier, qui permette de modifier la disposition des touches et de définir le type de clavier utilisé. Plusieurs mécanismes sont utilisables, cependant, il semble que ce qui est le plus utilisé actuellement est le mécanisme « Xkb » (abréviation de l'anglais « X KeyBoard »). Ce mécanisme permet de définir un grand nombre de données concernant le clavier, puisqu'outre l'emplacement des touches, il fournit la géométrie du clavier. Ainsi, toute application le désirant peut déterminer la forme du clavier et en dessiner une représentation fidèle.

Malheureusement, le protocole Xkb ne prévoit pas la possibilité de définir de nouvelles touches avec leurs scancodes. La gestion des codes reçus du clavier n'est en effet pas paramétrable. Par conséquent, il est impossible d'utiliser des claviers exotiques si ceux-ci ne sont pas reconnus par X.org.

Le protocole Xkb utilise les fichiers de configuration stockés dans le répertoire /etc/X11/xkb/. Ce répertoire contient un certain nombre de sous-répertoires, dont chacun est relatif à un des aspects de la configuration du clavier. Le rôle des principaux sous-répertoires est détaillé dans le tableau suivant :

Nom du répertoire	Fonction
geometry/	Contient les fichiers de description de la géométrie des claviers. Ces fichiers peuvent être utilisés par les applications pour obtenir une représentation graphique du clavier.
keycodes/	Contient les fichiers de définitions des « keycodes » X du clavier. Les keycodes X ont la même fonction que les keycodes de Linux : donner un nom unique à chaque touche. Cependant, ils diffèrent des keycodes de Linux en ce sens qu'ils ne sont pas définis à partir des scancodes du clavier, mais à partir de codes numériques générés par le serveur X. Ce mécanisme suppose que le serveur X connaisse tous les scancodes envoyés par les claviers. Comme il est impossible de déclarer de nouvelles séquences de scancodes au niveau du serveur X, on ne peut pas compléter les définitions de clavier existantes pour prendre en charge d'éventuelles nouvelles touches.
symbols/	Contient les définitions des plans de clavier ou, autrement dit, les associations entre les keycodes X et les symboles obtenus lors de l'appui sur les touches.
rules/	Contient les définitions des modèles de clavier de X.org. Ces modèles de clavier sont utilisés pour simplifier la définition des claviers dans le fichier de configuration xorg.conf.
keymaps/	Contient les définitions des principaux claviers connus. Une définition de clavier comprend entre autres la définition des keycodes, des touches modificatrices et des symboles affectés aux keycodes.

Il est probable que vous n'ayez pas à modifier un seul des fichiers de ces répertoires, car ils sont correctement définis par défaut. Le seul fichier qui peut être intéressant est le fichier fr du sous-répertoire symbols/. En effet, c'est dans ce fichier que vous trouverez la définition des symboles affectés à chaque touche pour un clavier français, en fonction des modificateurs (ALT, CTRL, etc.) actifs lors de l'appui sur la touche. Le principe de fonctionnement de ce fichier est semblable aux plans de claviers de Linux : pour chaque keycode, un ensemble de symboles peuvent être définis. Ces symboles sont indiqués entre accolades (caractères '{' et '}'), en deux jeux de symboles entourés de crochets (caractères '[' et ']'). Le premier jeu de symboles indique les symboles accessibles directement et en utilisant la touche majuscule, et le deuxième jeu définit les symboles accessibles avec la combinaison de la touche AltGr.

Par exemple, la touche du chiffre '3' au-dessus des lettres 'Z' et 'E' est définie comme suit dans le fichier de définition du clavier français (fichier fr) :

Sélectionnez

key <AE03> { [ quotedbl,   3        ],
             [ numbersign, sterling ] };

Cela signifie que la touche dont le keycode est « <AE03> » (c'est-à-dire celle la quatrième de la deuxième rangée de touches du clavier) génère les symboles « " » et « 3 » selon que la touche majuscule est utilisée ou non, et les symboles « # » et « Â£ » respectivement en minuscule ou en majuscule et avec la touche AltGr enfoncée.

Si vous regardez le fichier du clavier français, vous constaterez que toutes les touches ne sont pas définies. La raison de cela est que ces fichiers utilisent par défaut les affectations de touches du clavier américain standard. Par conséquent, seules les différences ont été redéfinies dans ce fichier.

Vous pourrez éventuellement modifier certaines affectations de touches si vous le désirez. Ce peut être nécessaire si vous désirez homogénéiser les combinaisons de touches entre la console Linux et XWindow. Par exemple, il peut être utile de redéfinie le comportement de la touche 'E' pour qu'elle renvoie le symbole Euro (caractère 'â‚¬') en combinaison avec la touche AltGr. Pour cela, vous pourrez utiliser la configuration suivante dans le fichier de clavier utilisé :

Sélectionnez

key <AD03> { [ e,          E        ],
             [ currency,   E        ] };

Note : Notez que la touche Euro est déjà accessible par défaut sur les claviers français avec la touche des monnaies (Livre Sterling, Dollar).

Une autre touche qui peut être redéfinie pour un clavier français est la touche 'O', afin de lui faire générer les symboles e dans l'o français ('œ' et 'OElig;') au lieu des symboles o barrés ('ø' et 'Ø') norvégiens, qui ne sont pas très utiles en français. Notez que les noms de symboles utilisés dans les tables d'encodage correspondent aux symboles de l'encodage ISO 8859-1, et que par conséquent, vous devrez utiliser les noms de symboles « onehalf » et « onequarter » pour représenter les caractères 'œ' et 'Å’'. En effet, ces symboles sont les symboles de l'encodage ISO 8859-1 qui ont le même code que les symboles 'œ' et 'Å’' dans l'encodage ISO 8859-15.

Sachez enfin que l'obtention de ces symboles est bien entendu assujettie à l'utilisation d'une police de caractères utilisant l'encodage ISO 8859-15.

Comme vous avez dû le constater, un certain nombre de plans de clavier sont définis en standard dans X.org. De même, plusieurs géométries et définitions de keycodes sont fournies dans les sous-répertoires geometry/ et keycodes/ du répertoire /etc/X11/xkb/. Le serveur X utilise les fichiers qui sont référencés dans la section « Keyboard » du fichier de configuration xorg.conf. Comme on l'a déjà vu plus haut dans ce chapitre, le mot clé « XkbLayout » permet de définir le plan de clavier à utiliser. Ainsi, si vous spécifiez le plan de clavier « fr » à la suite de ce mot clé, le fichier de définition des associations keycodes-symboles utilisé sera le fichier fr du répertoire /etc/X11/xkb/symbols/. Les autres options sont fixées par les mots clés « XkbRules » et « XkbModel ». Le premier mot clé indique quel est le fichier à utiliser pour définir les modèles de claviers de X.org. Ce fichier est localisé dans le sous-répertoire rules/, et fournit les valeurs par défaut à utiliser pour chaque modèle de clavier. Le deuxième mot clé indique le modèle de clavier à utiliser. Ainsi, il n'est nécessaire de spécifier que trois paramètres pour définir le clavier sous X.org : le fichier contenant la définition des modèles de clavier, le modèle lui-même et le fichier définissant la disposition des touches.

Note : Vous pouvez également définir tous les paramètres du clavier dans le fichier xorg.conf. Cette technique est plus compliquée et n'est pas nécessaire pour définir un clavier français, elle ne sera donc pas décrite ici. Vous trouverez plus de renseignements à ce sujet dans la page de manuel xorg.conf.

X-F. Paramétrage des applications et ressources X▲

Du fait que toutes les applications X font appel au serveur X pour effectuer leur affichage, et au gestionnaire de fenêtres pour définir l'apparence et la disposition de leurs fenêtres, elles sont soumises aux options générales de ces deux programmes. Elles peuvent cependant être paramétrées elles aussi, et leur comportement peut être personnalisé à souhait par chaque utilisateur.

Pour cela, XWindow fournit un mécanisme standard pour toutes les applications, afin qu'elles puissent gérer leurs options de configuration de manière uniforme. Ce mécanisme se base sur des paramètres gérés par le serveur X, que l'on appelle des ressources X. La plupart des applications utilisent ces ressources pour stocker leurs paramètres de configuration, et le fait que ce soit le serveur X qui centralise leur gestion assure une certaine cohérence entre les applications. En général, les ressources X décrivent essentiellement les aspects visuels des applications, par exemple les polices de caractères utilisées, les couleurs et l'épaisseur des traits. Cependant, les applications peuvent parfaitement utiliser les ressources pour enregistrer des paramètres qui leur sont propres. Le serveur X n'interprète en aucune manière les ressources utilisées par les applications, il ne fait que les mettre à disposition des applications.

Le serveur X gère les ressources dans une base de données qui est initialisée lors de son démarrage : la « X Ressource DataBase » (« xrdb » en abrégé). Cette base de données est initialisée lors du démarrage du serveur à partir de fichiers de configuration au format texte, que l'on peut donc éditer et modifier aisément. Le serveur X utilise deux jeux de fichiers lors de son initialisation : les fichiers de configuration par défaut des applications d'une part, et le fichier de préférences personnelles de chaque utilisateur d'autre part. Les fichiers de configuration des applications sont normalement placés dans le répertoire /etc/X11/app-defaults/. Les applications y copient leurs propres fichiers lors de leur installation. Le nom de chaque fichier correspond au nom de l'application à laquelle il appartient, ce qui permet de retrouver aisément le fichier de configuration d'une application donnée. Le fichier de préférences personnelles de chaque utilisateur, quant à lui, se place dans son répertoire racine et porte le nom .Xresources.

Les fichiers de ressources des applications sont lus en premier, en général dans les scripts d'initialisation de XWindow. En revanche, le fichier de préférences personnelles d'un utilisateur n'est lu que lors de l'ouverture d'une session X par cet utilisateur. Lorsqu'une ressource présente dans le fichier de configuration par défaut d'une application est redéfinie dans le fichier de préférences personnelles d'un utilisateur, la valeur utilisée est bien entendu celle de l'utilisateur. Ainsi, chacun peut redéfinir les valeurs par défaut des ressources de toutes les applications qu'il utilise. La plupart des applications peuvent également prendre des options en paramètres de ligne de commande, qui permettent de fixer les valeurs de certaines ressources. Ces options prévalent sur les valeurs définies dans les fichiers de configuration des applications et de préférences personnelles des utilisateurs.

Vous pourrez vous inspirer du contenu des fichiers de configuration des applications pour paramétrer vos applications. Pour cela, il vous suffira simplement de recopier les définitions des ressources qui vous intéressent dans votre fichier .Xresources, et de tester le résultat avec différentes valeurs. L'affectation d'une valeur à une ressource se fait avec la syntaxe suivante :

Sélectionnez

ressource    : valeur

où ressource est le nom de la ressource, et valeur est la valeur à lui affecter.

Les noms de ressources sont structurés de manière hiérarchique. Ils sont en effet constitués d'un certain nombre de composantes séparées par des points (caractère '.'). La première composante qualifie l'application elle-même, et porte son nom. Il est d'usage de mettre la première lettre de ce nom en majuscule, et si cette lettre est un 'X', de mettre également la deuxième lettre du nom en majuscule (beaucoup d'applications X ont en effet un nom commençant par un 'X'). Les composantes suivantes définissent un sous-ensemble de paramètres apparentés dans l'ensemble des paramètres déterminé par les composantes précédentes. Enfin, la dernière composante du nom de ressource constitue le nom du paramètre lui-même.

Par exemple, le nom de ressource suivant :

Sélectionnez

XApplication.mainWindow.background

qualifie la couleur d'arrière-plan (propriété « background ») de la fenêtre principale (propriété « mainWindow ») de l'application « XApplication ». Notez que les deux premières lettres du nom de la ressource sont en majuscules ici, car la première lettre du nom de l'application est elle-même un 'X' majuscule.

Note : Les fichiers de ressources utilisent des noms de couleurs prédéfinies pour définir les couleurs des différentes parties des applications. Vous pourrez trouver la liste de ces noms de couleurs ainsi que leurs définitions dans le fichier /usr/share/X11/rgb.txt. Vous pouvez également définir vos propres couleurs avec la syntaxe « rgb:R/V/B », où « R » représente la portion de rouge de la couleur, « V » représente la portion de vert, et « B » la portion de bleu.

Ainsi, l'ensemble des paramètres des applications X est organisé un peu comme sont organisés les fichiers dans une arborescence de répertoires. L'analogie ne s'arrête pas là : il est possible de caractériser un ensemble de ressources grâce à des caractères génériques. Par exemple, en utilisant une étoile (caractère '*') comme séparateur à la place du point dans un nom de ressource, toutes les ressources dont le nom comprend les deux composantes seront sélectionnées, que ces deux composantes soient adjacentes ou séparées d'autres composantes intermédiaires. Par exemple, le nom de ressource suivant :

Sélectionnez

XApplication*background

qualifie la couleur d'arrière-plan de toutes les fenêtres de l'application « Xapplication ».

De même, le caractère générique point d'interrogation (caractère '?') permet de remplacer une composante par un nom quelconque. Le nom de ressource suivant :

Sélectionnez

XApplication.?.background

représente donc toutes les ressources comportant les composantes « XApplication » et « background », séparées par une composante de nom quelconque.

La structure des noms de ressources d'une application n'est pas due au hasard. Les paramètres sont regroupés soit par fonctionnalité, soit par thème, soit par appartenance à la même partie de l'application. En général, les noms de ressources utilisés par les applications sont simples à comprendre. Vous trouverez des exemples de noms de ressources dans les fichiers de ressources des applications.

Vous pouvez obtenir la liste exhaustive des ressources d'une application avec l'utilitaire appres. En fait, cet utilitaire permet d'obtenir la liste des noms des ressources appartenant à une branche de l'arborescence des ressources. Cet utilitaire s'utilise selon la syntaxe suivante :

Sélectionnez

appres branche

où branche est le nom de la branche que l'on veut explorer.

Comme la base de données des ressources est initialisée au démarrage du serveur X et à l'ouverture de la session X, les modifications que vous pourrez apporter à votre fichier de ressources personnelles ne seront pas prises en compte immédiatement. Pour cela, vous devez demander la relecture de la base de données explicitement et relancer les applications concernées. Cette opération peut être effectuée à l'aide de l'outil xrdb (abréviation de l'anglais « X ressource DataBase »). En fait, cet outil permet d'effectuer diverses opérations sur la base de données des ressources.

L'option -merge est certainement celle que vous utiliserez le plus. Elle permet de mettre à jour les valeurs des ressources avec celles décrites dans un fichier. La syntaxe utilisée est la suivante :

Sélectionnez

xrdb -merge fichier

où fichier est le nom du fichier contenant la définition des ressources (généralement, il s'agit de votre fichier .Xresources).

L'option -load permet d'effectuer le même travail, mais la base de données est vidée au préalable. Cette option permet donc de réinitialiser complètement le contenu de la base de données avec le contenu du fichier passé en paramètre. Sa syntaxe est la même que celle de l'option -merge.

L'option -remove permet de vider la base de données et de supprimer toutes les ressources que vous auriez pu définir au préalable. Elle s'utilise selon la syntaxe suivante :

Sélectionnez

xrdb -remove

Enfin, l'option -query permet de lister l'ensemble des ressources existantes.

X-G. Gestion de la sécurité sous XWindow▲

XWindow n'effectue pas de contrôle d'accès sur les opérations demandées par un processus connecté à un serveur X. Cela signifie que tous les processus qui ont accès à un display y ont un accès total. Par exemple, un processus peut parfaitement faire une prise d'écran et récupérer tous les événements provenant du clavier. Il va de soi que ce genre de processus pose un problème de sécurité majeur, aussi XWindow considère-t-il que seuls les processus lancés sur la machine locale au nom de l'utilisateur courant ont le droit de se connecter au serveur X. Cela protège donc le display de l'utilisateur contre les malversations de personnes mal intentionnées.

Cependant, cette restriction est assez forte, parce qu'elle va vous empêcher de lancer un programme graphique sous un autre nom d'utilisateur. Par exemple, vous ne pourrez pas lancer un programme nécessitant les droits administrateur et dont le bit setuid n'est pas positionné. En effet, une fois que vous vous serez identifié en tant que root avec la commande su, les programmes que vous lancerez le seront au nom de l'utilisateur root, et le serveur X refusera la connexion. Un autre cas d'école où cette restriction peut être gênante est le lancement d'un programme graphique sur une machine distante. La situation est encore plus grave, car cette fois la demande de connexion au serveur X ne provient pas de la machine où il s'exécute, et n'a aucune chance d'aboutir.

XWindow fournit donc les outils nécessaires pour contrôler le niveau de sécurité en cours. Classiquement, le serveur X utilise deux techniques pour contrôler la validité des demandes de connexion des clients. Le premier mécanisme de contrôle d'accès est relativement grossier, puisqu'il se base simplement sur les adresses des machines. Le deuxième mécanisme a été introduit ultérieurement afin de permettre des contrôles plus fins. Les contrôles se font alors à l'aide d'un mécanisme de clés privées, que seuls les clients autorisés connaissent.

X-G-1. La commande xhost▲

La commande xhost permet de fixer le niveau des contrôles d'accès basés sur les adresses de machines. Comme on l'a vu, le serveur X n'accepte les connexions que de la machine locale. Vous pouvez cependant lui indiquer d'accepter toutes les connexions provenant d'une autre machine avec une commande telle que celle-ci :

Sélectionnez

xhost +machine

où machine est le nom de la machine en qui l'on a confiance. Si aucun nom de machine n'est spécifié, tous les mécanismes de contrôle d'accès sont désactivés.

Inversement, la suppression d'une machine de la liste des machines autorisées est réalisée par la commande suivante :

Sélectionnez

xhost -machine

La commande xhost - (sans nom de machine) permet de réactiver les mécanismes de contrôle d'accès s'ils ont été désactivés par un xhost +.

Notez bien que donner le droit de connexion à une machine suppose que l'on fasse confiance à tous les utilisateurs de cette machine, car alors ils pourront tous se connecter sur votre serveur X local. De plus, rien ne vous garantit que la machine à qui vous donnez ces droits n'a pas été usurpée par celle d'un pirate (technique dite de l'« IP spoofing »). Ce n'est donc évidemment pas la solution recommandée, surtout si vous êtes connecté à Internet.

X-G-2. La commande xauth▲

Le deuxième mécanisme de sécurité utilise une clé privée. Tous les clients qui désirent se connecter au serveur local doivent connaître cette clé, faute de quoi leur requête sera refusée. Ainsi, vous pouvez très simplement permettre l'utilisation de votre display à une personne donnée sur une machine donnée, simplement en lui communiquant la clé utilisée par le serveur X gérant votre display. Bien entendu, cette communication doit se faire de manière sûre.

Par défaut, les clés privées utilisées par les clients sont enregistrées dans le fichier .Xauthority de votre répertoire personnel. Ce fichier contient une clé privée pour chaque display auquel vous avez le droit de vous connecter. Les clients que vous lancez consultent donc ce fichier afin de déterminer la clé à utiliser, en fonction du display auquel ils désirent accéder. Une fois cette clé connue, ils peuvent s'authentifier auprès du serveur X gérant ce display, et ainsi obtenir une connexion. Notez bien que le fichier .Xauthority ne doit être accessible que par vous.

Si vous utilisez xdm, une nouvelle clé est automatiquement générée à chaque fois que vous vous connectez à un terminal X. xdm enregistre cette clé dans un fichier temporaire du répertoire référencé par le lien symbolique /etc/X11/xdm/authdir (qui référence généralement le répertoire /var/lib/xdm/authdir/), que seul l'utilisateur root peut accéder. Il communique ensuite ce fichier au serveur X local à l'aide de l'option -auth du serveur X pour que celui-ci puisse lire la clé à utiliser. Enfin, xdm enregistre cette clé dans votre fichier .Xauthority, pour que vous puissiez lancer des clients dans cette session X.

Comme vous pouvez le constater, ce mécanisme de sécurité est totalement transparent pour l'utilisateur. Cependant, il peut être nécessaire de manipuler le fichier .Xauthority pour lire les clés privées et les communiquer aux personnes de confiance qui doivent avoir accès à votre display. Ces manipulations peuvent être effectuées à l'aide de la commande xauth.

La clé associée à un display peut être obtenue avec la commande suivante :

Sélectionnez

xauth list display

où display est le nom du display auquel la clé donne accès. xauth affiche alors le display, le type d'authentification utilisé (MIT-MAGIC-COOKIE-1) et la clé privée.

Vous pouvez communiquer cette clé par les moyens que vous voulez à la personne devant accéder à votre display. Celle-ci pourra alors utiliser la commande suivante pour ajouter la clé à son fichier .Xauthority :

Sélectionnez

xauth add display . clé

où display est le display utilisant la clé clé. Le caractère '.' est une abréviation pour le type d'authentification « MIT-MAGIC-COOKIE-1 » (type d'authentification par défaut). Dès que la clé aura été ajoutée dans son fichier .Xauthority, cette personne aura accès à votre display.

Enfin, la commande suivante :

Sélectionnez

xauth remove display

permet de supprimer la clé utilisée pour le display display.

Note : Il est nécessaire d'utiliser une technique de communication sûre pour transmettre la clef, faute de quoi le mécanisme de sécurité de XWindow ne servirait à rien. L'utilisation d'OpenSSH est vivement recommandée.

X-H. Gestion des polices de caractères▲

La gestion des polices de caractères est relativement compliquée sous XWindow. En effet, elle est gérée par un protocole complexe, qui permet de décrire avec précision les diverses polices de caractères, quels que soient leur type et leur aspect. De plus, la gestion des polices nécessite de traiter correctement les symboles spécifiques à chaque pays, ce qui complique encore un peu plus les choses. Enfin, pour couronner le tout, XWindow n'utilise pas la notion de graphisme indépendant du périphérique, comme la GDI de Windows. Cela implique, hélas, qu'il ne se charge que de l'affichage et pas de l'impression. Chaque programme doit donc prendre en compte lui-même les problèmes d'impression, ce qui implique, en général, que les programmes soient capables d'imprimer sur des imprimantes PostScript. Par conséquent, la configuration des polices de caractères doit non seulement se faire pour XWindow, mais également pour chacun des programmes (ou, au moins, pour l'interpréteur GhostScript, utilisé pour l'impression avec des imprimantes non PostScript).

X-H-1. Gestion des polices de caractères sous XWindow▲

Originellement, XWindow ne pouvait afficher que des polices de type bitmap, c'est-à-dire des polices de caractères définies par un dessin pour chaque caractère et pour un certain nombre de résolutions. Cette technique avait l'avantage d'être rapide à l'affichage, mais de relative mauvaise qualité lorsque les tailles demandées n'étaient pas exactement celles pour lesquelles la police avait été dessinée. En effet, la police devait alors être redimensionnée à partir de la taille la plus proche disponible. Ultérieurement, les polices Postscript sont apparues. Ces polices sont définies vectoriellement, c'est-à-dire par des formules mathématiques. La forme des caractères est ainsi calculée pour chaque dimension, ce qui permet d'avoir une qualité irréprochable. L'avantage des polices Postscript est qu'elles sont gérées de manière native par les imprimantes PostScript, et assurent une qualité d'impression optimale. En revanche, leur affichage sur les écrans n'est pas toujours correct, car les formules utilisées ont été conçues pour les périphériques disposant de grandes résolutions et ne donnent pas forcément un résultat esthétique pour les résolutions d'écrans. Enfin, les polices Truetype ont été inventées par Apple. Ces polices sont également vectorielles, mais disposent en plus de petites astuces permettant d'améliorer leur lisibilité sur les périphériques à faible résolution tels que les écrans. Microsoft a licencié la technologie Truetype et l'a intégrée à Windows par la suite.

Afin de décrire les polices le plus précisément possible, XWindow leur donne des noms relativement complexes. Ces noms constituent ce que l'on appelle la description logique des polices (« XLFD », qui est l'abréviation de l'anglais « X Logical Font Description »). Cette convention de dénomination spécifie que la description des polices doit être constituée de différents champs, séparés par des tirets ('-'). De plus, la description doit elle-même être précédée d'un tiret. Les différents champs utilisés dans la description logique des polices sont les suivants :

le nom de l'éditeur de la police, ou le nom du type de la police ;
le nom de la police (par exemple, « arial ») ;
la graisse de la police (par exemple, « bold » pour gras, « medium » pour normal) ;
l'inclinaison de la police (par exemple, 'r' pour roman, 'i' pour italique) ;
la largeur de la police ;
des options de styles avancées ;
la taille de la police ;
la taille des points ;
la résolution horizontale de la police ;
la résolution verticale ;
le type d'espacement de la police (par exemple, 'c' pour constant, 'p' pour proportionnel) ;
la largeur moyenne de la police ;
le jeu de caractères de la police ;
la page de codes de la police.

Vous pouvez consulter la documentation de XWindow pour une description plus détaillée de ces champs. Ces informations ne sont pas toutes supportées par les polices de caractères. Inversement, certaines polices peuvent correspondre à plusieurs descriptions (ne serait-ce que parce qu'elles disposent de plusieurs tailles).

Parmi les informations décrivant les polices se trouvent le jeu de caractères de la police et sa page de codes (rappelons que ces informations constituent ce que l'on appelle l'encodage de la police). Il peut y avoir plusieurs pages de codes pour un jeu de caractères, chacune représentant une manière de numéroter les différents caractères du jeu. Une police peut disposer de plusieurs jeux de caractères, mais en pratique ce n'est que rarement le cas. En revanche, la manière de numéroter les caractères (c'est-à-dire la page de codes) peut avoir une influence certaine.

Comme on le verra plus tard, le jeu de caractères le plus pratique pour les pays d'Europe de l'Ouest est le jeu ISO 8859 (jeu de caractères dit « latin »). Ce jeu de caractères dispose de la plupart des caractères utilisés en Europe. Pour les alphabets occidentaux, la page de codes la plus utilisée est la page de codes 1, ce qui fait que l'encodage des polices occidentales est ISO 8859-1. Cependant, quelques caractères ont été oubliés dans cette page de codes (notamment le o e dans l'o français ('œ')). Ces caractères sont pourtant disponibles dans certaines polices (en particulier, les polices Truetype provenant de Windows), mais ne sont malheureusement pas disponibles avec l'encodage ISO 8859-1. Pour y accéder, on est obligé d'utiliser un autre encodage, par exemple l'encodage ISO 8859-15. Cet encodage est quasiment identique à l'encodage ISO 8859-1, aux caractères additionnels près, qui ont été ajoutés pour les pays européens. Il est également possible d'utiliser la page de codes 1252 des polices de caractères de Windows. Cette page de codes correspond à l'encodage « windows-1252 », parfois également nommé « microsoft-ansi » ou encore « microsoft-cp1252 ». En résumé, le jeu de caractères et la page de codes permettent d'indiquer pour quel pays (ou quel alphabet) une police est destinée.

Note : Le problème des encodages est que seul l'encodage ISO 8859-1 est vraiment utilisé par la majorité des gens. Cela implique que les autres encodages risquent de ne pas être reconnus par tous les programmes. En particulier, il est assez difficile d'imprimer des textes encodés avec des encodages non standards.

La description logique des polices de caractères est très précise, puisqu'elle permet de spécifier l'origine de la police, son nom, les informations la concernant, les caractères qu'elle comprend et comment ils sont numérotés. Lorsqu'on choisit une police de caractères, on peut parfaitement ne préciser que certains critères (par exemple, l'encodage de la police). Dans ce cas, les champs constituant le nom de la police non spécifiés pourront être remplacés par des caractères génériques. Le caractère '*' permet ainsi de spécifier n'importe quelle valeur pour ce champ, et le caractère '?' permet de spécifier n'importe quel caractère dans un champ.

Le programme xfontsel permet de sélectionner les polices de caractères installées sur un système. Il peut être utile pour comprendre la signification des différents champs de la description logique des polices. Des exemples de descriptions logiques de polices sont donnés ci-dessous :

Sélectionnez

-adobe-helvetica-medium-r-*-*-12-*-*-*-*-*-iso8859-1
-*-courier-bold-*-normal-*-10-*-*-*-*-*-iso8859-15
-winfonts-arial-*-i-normal-*-16-*-*-*-*-*-microsoft-cp1252

Les polices de caractères sont souvent regroupées dans des répertoires. Il peut exister plusieurs répertoires de polices sur un système, si bien qu'il est nécessaire d'indiquer à X.org dans quels répertoires il doit rechercher les polices de caractères utilisables. Les répertoires des polices utilisées par le serveur X sont indiqués dans le fichier xorg.conf, dans la section « Files ». Comme on le verra plus tard, cette section peut également contenir des références sur des serveurs de polices de caractères. Les serveurs de polices de caractères peuvent rechercher les polices dans des répertoires indiqués de différentes manières selon le serveur. Pour certains serveurs, les répertoires de polices sont indiqués dans un fichier de configuration, pour d'autres, ils sont indiqués en ligne de commande.

Dans le protocole X, les répertoires de polices doivent contenir un fichier fonts.dir donnant la liste des polices de ce répertoire. Ce fichier indique, sur sa première ligne, le nombre de polices installées dans ce répertoire, et, sur les lignes suivantes, l'association entre les fichiers de polices et leur description logique. Ce fichier est créé normalement par le programme mkfontdir. Ce programme génère le fichier fonts.dir à partir des informations contenues dans les fichiers des polices ou à partir du nom des fichiers des polices eux-mêmes. En général, les polices à taille variable ne contiennent pas ces informations dans le format standard des polices X11 classiques, et mkfontdir ne peut donc pas créer le fichier fonts.dir automatiquement. Pour ces polices, il faut créer un fichier fonts.scale contenant les mêmes informations que le fichier fonts.dir, et que mkfontdir utilisera pour créer ce dernier. La méthode pour créer le fichier fonts.scale dépend du type de police utilisée. Celle utilisée pour les polices Truetype sera décrite dans la Section 10.8.2.

En général, les encodages les plus standards sont gérés directement par le serveur X ou par le serveur de polices. En particulier, l'encodage ISO 8859-1 est géré nativement. Il est toutefois possible de définir de nouveaux encodages dans des fichiers d'encodages. Pour que le serveur X ou le serveur de polices puisse utiliser les polices définies avec ces encodages, il faut que le répertoire d'installation des polices contienne un fichier encodings.dir. Ce fichier a la même structure que le fichier fonts.dir, c'est-à-dire qu'il contient le nombre des encodages sur la première ligne et, sur chaque ligne suivante, le nom de l'encodage et le nom d'un fichier contenant la définition d'un encodage, séparés par un espace. De cette manière, le serveur X et le serveur de polices sont capables de réaliser l'association entre le nom de l'encodage utilisé dans la description logique de polices et le fichier de définition de cet encodage. La méthode permettant de créer le fichier encodings.dir sera décrite plus loin dans la section traitant de l'installation des polices Truetype.

L'écriture des fichiers de définition d'encodages de polices est une tâche assez compliquée, qui nécessite de bien connaître la numérotation des caractères de chaque type de fichier de police. De manière très simplifiée, on peut dire que les fichiers de définition d'encodage font l'association entre le numéro de chaque caractère dans la police et une numérotation standardisée des caractères (XWindow utilise l'encodage Unicode) de cette police. Cela permet de manipuler les textes avec la numérotation standard, et d'utiliser des polices qui ne définissent pas tous les caractères de cette numérotation ou qui ne les numérotent pas de la même manière. Heureusement, les encodages les plus courants ont déjà été écrits et il est fort peu probable que vous ayez à vous intéresser à ce problème. La structure des fichiers d'encodages ne sera donc pas décrite plus en détail dans ce document.

X-H-2. Installation des polices Truetype▲

L'installation des polices TrueType sous XWindow ne pose désormais plus de problèmes, puisqu'il suffit de définir le fichier fonts.dir dans le répertoire d'installation de ces polices. Cependant, un certain nombre d'opérations supplémentaires devront être réalisées pour permettre l'impression des documents utilisant les polices TrueType. Ce paragraphe détaille la manière de déclarer les polices TrueType au niveau du serveur X, et présente les opérations nécessaires à leur impression pour quelques logiciels courants.

Généralement, les fichiers de polices sont placés dans des sous-répertoires du répertoire /usr/share/fonts/. Ces sous-répertoires permettent de classer les fichiers de polices par type et par taille. Dans la suite de ce document, il sera supposé que les polices TrueType sont toutes situées dans le sous-répertoire TTF/.

X-H-2-a. Configuration du serveur X▲

Pour permettre au serveur X d'utiliser les polices TrueType, il faut simplement écrire le fichier fonts.dir de chaque répertoire de polices. Rappelons que ce fichier contient la liste des polices du répertoire dans lequel il se trouve, et est utilisé à la fois par le serveur X et par les serveurs de polices de caractères. La notion de serveur de polices sera vue en détail dans la Section 10.8.3.

Normalement, le fichier fonts.dir est généré par le programme mkfontdir. Ce programme utilise les informations contenues dans les fichiers de polices ou dans le nom de ces fichiers pour le générer. Malheureusement, les polices Truetype, comme la plupart des polices à taille variable, ne contiennent pas ces informations dans un format compréhensible par mkfontdir, ni dans leurs fichiers, ni dans leurs noms. Celui-ci ne peut donc pas créer le fichier fonts.dir directement. Dans ce cas, mkfontdir utilise le fichier de définition des polices à taille variable fonts.scale. Ce fichier doit être créé soit manuellement, soit à l'aide de l'utilitaire mkfontscale. Celui-ci doit être appelé dans le répertoire contenant les polices de caractères, et génère un fichier fonts.scale directement utilisable par mkfontdir.

Une fois le fichier fonts.scale créé, il ne reste plus qu'à appeler mkfontdir avec la ligne de commande suivante :

Sélectionnez

mkfontdir -e /usr/share/fonts/encodings -e /usr/share/fonts/encodings/large

Cette commande aura pour effet de créer le fichier fonts.dir à partir du fichier fonts.scale, et de créer les fichiers d'encodage encodings.dir associés (en fait, il s'agit d'une simple recopie). mkfontdir utilise les fichiers de définition d'encodages standards placés dans les répertoires indiqués avec l'option -e. Dans la commande précédente, les encodages standards supportés par XWindow du répertoire /usr/share/fonts/encodings/ sont utilisés.

Note : L'encodage Microsoft cp1252 correspond à l'encodage « ANSI » utilisé par Microsoft Windows. C'est un encodage non standard, qui ressemble fortement à l'encodage ISO 8859-1 spécifié par l'ISO. Ce dernier souffre malheureusement de l'absence de certains caractères français (comme le o e dans l'o). Si vous voulez rester compatible avec les normes ISO et accéder malgré tout à ces caractères, vous pouvez utiliser l'encodage ISO 8859-15. Vous accéderez ainsi à tous les caractères utilisés en Europe, mais vous ne pourrez plus utiliser les caractères additionnels définis par Microsoft.

Il faut noter que la plupart des polices sont défectueuses et indiquent une page de codes erronée dans leur fichier. Cela explique pourquoi quelques descriptions logiques de polices dans le fichier fonts.scale généré automatiquement par mkfontscale peuvent être fausses. Pour ces polices, il faudra corriger l'encodage manuellement en modifiant le fichier fonts.scale avant d'exécuter la commande mkfontdir.

X-H-2-b. Configuration des polices Truetype pour l'impression▲

La plupart des programmes modernes, comme la suite bureautique OpenOffice et les programmes du gestionnaire de bureau KDE par exemple, prennent en charge complètement les polices de caractères TrueType tant pour l'affichage que pour l'impression. En général, ils impriment dans des fichiers au format PostScript, et embarquent la définition des polices de caractères TrueType dans ces fichiers, qui sont utilisables de manière indépendante. Vous n'aurez donc certainement rien à faire pour pouvoir utiliser les polices TrueType à l'impression .

Cependant, les plus anciens programmes se contentent de référencer les polices utilisées dans les fichiers d'impression, et il faut configurer le sous-système d'impression pour qu'il puisse reconnaître ces polices et les imprimer correctement. D'une manière générale, deux cas peuvent se présenter :

soit on dispose d'une imprimante PostScript, auquel cas il faut convertir les polices Truetype en polices Adobe Type 42, qui constituent une encapsulation des polices Truetype en PostScript. Cette conversion a l'avantage de ne pas provoquer de perte de qualité, puisque la police Truetype est utilisée telle quelle ;
soit on ne dispose pas d'imprimante PostScript, auquel cas on utilise nécessairement un interpréteur PostScript. Cet interpréteur est souvent GhostScript, car il s'agit encore une fois d'un logiciel libre. Quel que soit l'interpréteur PostScript utilisé, il faut soit le configurer pour qu'il puisse utiliser les polices Truetype, soit que les applications fournissent la définition des polices TrueType qu'elles utilisent dans les fichiers PostScript qu'elles génèrent lors de l'impression. Cette dernière solution est celle utilisée par les logiciels récents (comme les applications de KDE ou OpenOffice), ce qui fait qu'en général, les polices TrueType sont prises en charge sans configuration additionnelle. Nous verrons plus loin comment configurer les versions de GhostScript ultérieures à la 7.00 pour qu'elles puissent prendre en compte les polices TrueType pour les autres applications.

Dans les deux cas, il se peut qu'il faille configurer le logiciel utilisé pour qu'il puisse utiliser les polices Truetype de concert avec le sous-système d'impression.

Les paragraphes suivants décrivent les procédures à suivre pour imprimer les polices Truetype en général. La configuration des logiciels ne sera pas abordée, consultez leur aide ou recherchez des renseignements sur Internet quant à la procédure à suivre.

X-H-2-b-i. Conversion des polices Truetype en polices Adobe de Type 42▲

La conversion des polices Truetype en polices Adobe de Type 42 est une opération nécessaire si l'on utilise directement une imprimante PostScript ou si l'on utilise un interpréteur PostScript incapable de gérer directement les polices Truetype. De manière générale, il est recommandé d'utiliser GhostScript même si l'on possède une imprimante PostScript, car la configuration de l'impression se fait de la même manière que les autres utilisateurs de Linux, et il est donc plus facile de trouver de l'aide sur Internet.

La conversion en polices Adobe de Type 42 peut être réalisée avec le programme ttfps, disponible sur Internet sous le nom ttfps.tar.gz. Cet outil est tout à fait correct, mais il souffre d'un grave défaut : il ne permet pas de choisir l'encodage de la police PostScript qu'il génère. Plus grave encore, il utilise systématiquement l'encodage standard Adobe, qui ne dispose pas de la plupart des lettres accentuées françaises (c'est aussi la raison pour laquelle il est recommandé d'utiliser GhostScript). Vous pouvez bien entendu modifier le code source si vous vous en sentez le courage.

Vous devrez compiler ttfps pour pouvoir l'utiliser. Lorsque vous aurez extrait les fichiers sources de l'archive, vous aurez à éditer le fichier Makefile pour :

définir la variable d'environnement CC avec pour valeur le nom du compilateur que vous utilisez (en l'occurrence, gcc) :
Sélectionnez
```
CC=gcc
```
choisir entre les deux jeux d'options de compilation CFLAGS. Vous ne devez en choisir qu'un seul, il faut obligatoirement commenter l'autre avec un caractère dièse ('#'). Le choix dépend de l'architecture de votre machine. Si vous utilisez un PC, vous devrez choisir l'option contenant l'option -DSMALLENDIAN.

Une fois ces modifications faites, vous pourrez compiler ttsps avec la simple commande suivante :

Sélectionnez

make

L'utilisation de ttfps est très simple. Pour convertir une police Truetype en police Adobe de Type 42, il suffit d'utiliser la ligne de commande suivante :

Sélectionnez

ttfps [-a fichier.afm] fichier.ttf fichier.pfa

où fichier.afm est le nom du fichier de définition des dimensions de la police PostScript, fichier.ttf est le nom du fichier de police Truetype à encapsuler, et fichier.pfa est le nom de la police PostScript résultante. La génération du fichier .afm est facultative.

X-H-2-b-ii. Installation des polices Truetype pour GhostScript▲

GhostScript est un interpréteur PostScript capable d'imprimer les polices Truetype. Sa configuration est très simple, puisqu'il suffit de lui donner le nom de police que les fichiers PostScript utilisent pour la référencer et le nom du fichier de police correspondant. Cette association est définie dans le fichier Fontmap de GhostScript, que vous pourrez trouver dans son répertoire d'installation (normalement, GhostScript se trouve dans le répertoire /usr/share/ghostscript/version/, où version est le numéro de la version installée).

Les informations que vous devez ajouter dans ce fichier sont similaires à celles stockées dans le fichier fonts.dir du répertoire de polices. Pour chaque police, il faut rajouter une ligne de la forme suivante :

Sélectionnez

(nom) (fichier) ;

où nom est le nom de la police d'imprimante que les programmes utilisent dans les fichiers PostScript qu'ils génèrent, et fichier est le chemin absolu du fichier de la police Truetype.

En pratique, le nom de la police d'imprimante peut être choisi librement. On veillera toutefois à ne pas utiliser des noms de polices contenant des espaces, car certains programmes peuvent avoir du mal à manipuler de tels noms. Il faudra bien utiliser ce nom lors de la déclaration des polices d'imprimante dans les logiciels capables d'imprimer en PostScript. Si l'on ne peut pas définir ce nom au niveau des logiciels, il faudra ajouter un alias dans le fichier Fontmap de GhostScript pour chaque nom de police utilisé par les logiciels. Il n'existe pas de règle générale permettant de déterminer les noms de polices utilisés par les programmes. Le plus simple est peut-être dans ce cas de déterminer les noms utilisés en imprimant un document dans un fichier PostScript et en regardant dans le fichier les instructions de changement de police de caractères.

X-H-3. Configuration d'un serveur de polices▲

XWindow étant un système de fenêtrage fonctionnant en réseau, il propose des services additionnels sur le réseau en plus de l'affichage. Parmi ces services, on notera la possibilité de mettre en place des serveurs de polices de caractères. Ces serveurs permettent à des clients situés sur d'autres machines d'accéder à la définition des polices de caractères de la machine locale.

Le serveur de police fourni par XWindow se nomme « xfs » (abréviation de l'anglais « X Font Server »). Ce serveur utilise un fichier de configuration qui permet de lui spécifier les options avec lesquelles il doit démarrer. Dans la suite de ce document, le nom supposé de ce fichier est /usr/lib/X11/fs/config. Un fichier de configuration typique est donné ci-dessous :

Sélectionnez

# Exemple de fichier de configuration du serveur de police :

# Limite à 10 le nombre de clients connectés à ce serveur :
client-limit = 10

# Demande le démarrage d'un autre serveur quand la limite
# précédente est atteinte :
clone-self = on

# Répertoire des polices de caractères :
catalogue = /usr/share/fonts/TTF

# Fixe la taille par défaut (en dixièmes de points) :
default-point-size = 120

# Résolution par défaut (100 x 100 et 75 x 75) :
default-resolutions = 100,100,75,75

# N'utilise pas le mécanisme des traces du système :
use-syslog = off

# Utilise le fichier d'erreurs suivant à la place :
error-file = /root/xfs.errors

Lorsque vous aurez créé votre fichier de configuration, il ne vous restera plus qu'à tester si tout fonctionne bien. Il vous faut pour cela lancer le serveur de polices avec la ligne de commande suivante :

Sélectionnez

xfs -port 7100 -config /etc/xfs.conf &

et essayer de lui demander la liste des polices qu'il peut fournir :

Sélectionnez

fslsfonts -server localhost:7100

Si cette dernière commande échoue, il se peut que le chemin indiqué pour les répertoires de polices dans le fichier /usr/lib/X11/fs/config ne soit pas correct, ou que le fichier fonts.dir n'existe pas ou ne soit pas correct dans un des répertoires de polices.

Si vous le désirez, vous pouvez faire en sorte que le serveur de polices soit démarré automatiquement au lancement de X. Vous pourrez pour cela créer un script de lancement du serveur de polices, que vous placerez dans le répertoire /etc/rc.d/ (ou le répertoire /sbin/init.d/, selon votre distribution) pour lancer et arrêter le serveur de polices en suivant le mécanisme des niveaux d'exécution. Vous trouverez ci-dessous un exemple de script de lancement du serveur de polices permettant d'utiliser le fichier de configuration précédent :

Sélectionnez

#!/bin/bash
#
# /etc/rc.d/xfs
#
# Fichier de lancement du serveur de polices.
#

PORT=7100
FILE=/usr/lib/X11/fs/config
PRGM=/usr/bin/xfs

[ -f $PRGM ] || exit 0

# Analyse les paramètres :
case "$1" in
    start)
        # Vérifie si xfs est déjà lancé :
        if [ -f /var/lock/subsys/xfs ]; then
            echo -n "Redémarrage du serveur de polices"
            killall -e -TERM $PRGM
            rm -f /var/lock/subsys/xfs
        fi
        $PRGM -port $PORT -config $FILE &
        touch /var/lock/subsys/xfs
        ;;
    stop)
        if [ ! -f /var/lock/subsys/xfs ]; then
            echo -n "xfs n'est pas lancé"
        else
            echo -n "Arrêt du serveur de polices"
            killall -e -TERM $PRGM
            rm -f /var/lock/subsys/xfs
        fi
        ;;
    restart)
        echo -n "Relecture du fichier de configuration"
        if [ -f /var/lock/subsys/xfs ]; then
            killall -e -USR1 $PRGM
        fi
        ;;
    *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac
exit 0

Comme X11 est démarré classiquement dans le niveau d'exécution 3 ou 4, vous devrez créer les liens symboliques vers ce fichier pour le lancement et l'arrêt du serveur de polices dans le répertoire rc3.d/ ou rc4.d/. Attention, rappelez-vous que les noms de ces liens indiquent le moment où le script est exécuté, aussi bien pour l'entrée que pour la sortie du niveau d'exécution. Vous devrez impérativement faire en sorte que ce script soit appelé avant que XWindow ne démarre si vous désirez utiliser le serveur de polices dans les sessions X locales.

L'utilisation du serveur de polices est très simple. Il suffit d'y accéder comme à un répertoire de polices de caractères normal, en utilisant la syntaxe suivante :

Sélectionnez

tcp/machine:port

où machine est la machine sur laquelle le serveur de polices à accéder est lancé, et port est le port que ce serveur écoute. Par exemple, pour ajouter les polices d'un serveur de polices locales à la liste des polices du serveur X, il suffit de taper la commande suivante :

Sélectionnez

xset +fp tcp/127.0.0.1:7100

Vous pourrez alors vérifier que ces polices sont bien disponibles avec le programme xfontsel.

Si vous le désirez, vous pouvez ajouter automatiquement les polices d'un serveur de polices en ajoutant la ligne suivante dans la section « Files » dans le fichier de configuration xorg.conf du serveur :

Sélectionnez

FontPath "tcp/127.0.0.1:7100"

Cette ligne permet d'indiquer au serveur X qu'il trouvera des polices de caractères au niveau du serveur de polices de la machine locale. Bien entendu, le serveur de polices doit impérativement être lancé avant le serveur X si une telle ligne est placée dans le fichier de configuration xorg.conf.

X-I. Problèmes classiques rencontrés▲

Il est possible que vous rencontriez quelques problèmes au lancement de XWindow après avoir modifié sa configuration. Ces problèmes peuvent aller du blocage complet de la machine à l'impossibilité de lancer XWindow.

D'une manière générale, il est recommandé de ne pas modifier la configuration dans le niveau d'exécution de XWindow (3, 4 ou 5 selon les distributions). En effet, dans ces niveaux, xdm relance automatiquement le serveur X dès qu'il détecte sa terminaison. Si le serveur X ne peut pas se lancer, votre ordinateur se bloquera dans une boucle infinie, avec en prime deux changements de mode graphique à chaque itération (ce qui peut endommager sérieusement votre moniteur). Si cela vous arrivait, vous n'auriez plus qu'à tenter le redémarrage de la machine en basculant rapidement sur un terminal (avec CTRL+ALT+F1 suivi de CTRL+ALT+DEL. Faites-le très rapidement, avant que xdm n'ait le temps de tenter un redémarrage du serveur X !), et à redémarrer en indiquant le niveau d'exécution 2 à l'amorçage du noyau. Par conséquent, essayez vos changements de configuration dans le niveau d'exécution 2 si possible, et faites vos tests avec la simple commande startx.

Des erreurs un peu plus techniques peuvent provenir de la configuration réseau elle-même (n'oubliez pas que XWindow est un système graphique basé réseau). Les erreurs les plus effroyables sont sans doute les erreurs du type « _X11TransSocketINETConnect: Can't connect: errno = n », où n est un code d'erreur numérique. Typiquement, cette erreur signale un problème dans la configuration réseau. Les deux erreurs les plus classiques sont l'erreur 101, qui signale que la machine indiquée dans le display n'a pas pu être contactée, et l'erreur 111, qui signale que cette machine est bien accessible par le réseau, mais que le serveur X ne s'y trouve pas.

En général, vous devrez vérifier toute votre configuration réseau si vous rencontrez des erreurs 101, et le problème n'est certainement pas spécifique à XWindow. Vous pouvez également vérifier la validité de votre display, car il se peut qu'il désigne une machine inaccessible sur votre réseau (ou que la résolution de nom ait échoué pour cette machine).

Pour ce qui est de l'erreur 111, c'est beaucoup plus simple. Dans la grande majorité des cas, le serveur X désigné n'existe tout simplement pas. Il faut donc s'assurer que le serveur X en charge de gérer le display indiqué dans la variable d'environnement DISPLAY est bien lancé sur la machine désignée.

Enfin, lorsqu'une application cliente refuse de démarrer en affichant un message d'erreur « Can't open display: », c'est tout simplement que la variable d'environnement DISPLAY n'a pas été précisée, et que l'option en ligne de commande -display n'a pas été utilisée non plus. L'application ne sait donc tout simplement pas à quel display se connecter. Si le display a bien été défini, mais que le message « Can't open display:xxx » est complété du message « Connection to "xxx" refused by server » ou « Client is not authorized to connect to Server », c'est que le client a été lancé dans un autre compte utilisateur que le compte que vous utilisez couramment, et que ce compte ne dispose pas des droits nécessaires pour accéder à ce display. Vous devez dans ce cas donner l'accès à votre display au compte utilisateur sous lequel vous lancez le client.

Copyright © 2004-2020 Christian Casteyde. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.