| Guide d'installation et de configuration de Linux | ||
|---|---|---|
| Précédent | Chapitre 10. Installation de XWindow | Suivant |
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.6). 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 »).
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 puisse lui demander une connexion. Les serveurs X capable 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 environnement 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.
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 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.
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 :
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 nombres 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 XFree86. 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 :
/usr/X11R6/bin/X display vtNNoù 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 :
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 pas 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 XFree86 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 :
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.
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 directes 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'un 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 simplement d'indiquer la machine ou le groupe de machines. Par exemple, la ligne suivante :
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 :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 :
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 :
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 n'est pas capable. Il suffit pour cela de remplacer la liste des serveurs par le mot clé « BROADCAST ». Ainsi, la ligne suivante :
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 :
%nom listeoù 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à :
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 ».
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 XFree86 sera décrite ici.
Les serveurs X de XFree86 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 XFree86 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.
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 XFree86 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 /lib/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, comme 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 ou autre), qui permettent de représenter les choix que l'utilisateur a fait pour sa connexion dans la fenêtre de login. Par exemple, le premier paramètre de ce script est souvent le nom du gestionnaire de fenêtres à utiliser. 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 :
dans le fichier Xstartup, afin d'enregistrer les utilisateurs qui commencent une session XWindow, et une autre ligne telle que celle-ci : dans le fichier Xreset, afin de les supprimer lorsqu'ils terminent cette session.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 XFree86 XF86Config. Nous verrons donc ici comment modifier des paramètres qui tiennent plus de l'ergonomie que de la configuration de base.
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 :
permet d'éteindre l'écran au bout de dix minutes d'inactivité.Ces temps peuvent également être fixés dans le fichier de configuration XF86Config, 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 :
dans la section « Monitor » qui les définit.Note : Les valeurs des temps d'attente que vous pouvez fixer dans le fichier de configuration XF86Config 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 XF86Config 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/X11R6/lib/X11/fonts/100dpi/ à la liste des répertoires de polices du serveur, il suffit de taper la commande suivante :
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 XF86Config.
Enfin, l'option q de xset vous permettra de visualiser l'ensemble des paramètres en cours d'utilisation.
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 XFree86 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épendant 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 XFree86.
Le protocole Xkb utilise les fichiers de configuration stockés dans le répertoire /usr/X11R6/lib/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 XFree86. Ces modèles de clavier sont utilisés pour simplifier la définition des claviers dans le fichier de configuration XF86Config. |
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 jeux 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) :
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é :
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 o e dans l'o français ('½' et '¼') 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 (c'est le cas de ce document).
Sachez enfin que l'obtention de ces symboles est bien entendue 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 XFree86. 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 /usr/X11R6/lib/X11/xkb/. Le serveur X utilise les fichiers qui sont référencés dans la section « Keyboard » du fichier de configuration XF86Config. 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 /usr/X11R6/lib/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 XFree86. 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 XFree86 : 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 XF86Config. 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 XF86Config.
| Précédent | Sommaire | Suivant |
| Utilisation du pilote frame buffer du noyau | Niveau supérieur | Paramétrage des applications et ressources X |