| Guide d'installation et de configuration de Linux | ||
|---|---|---|
| Précédent | Chapitre 8. Configuration du matériel et des périphériques | Suivant |
Il existe un grand nombre de cartes filles sur le marché, dont les plus courantes sont sans doute les cartes graphique, les cartes son et les cartes réseau. Toutes ces cartes permettent d'ajouter des fonctionnalités de manière modulaire à une machine, en les enfichant dans les emplacements prévus à cet effet sur la carte mère.
Les cartes les plus vielles que l'on peut encore rencontrer sont les cartes ISA. La configuration de ces cartes a toujours été extrêmement difficile, en raison des nombreux conflits matériels qu'elles provoquaient entre elles et avec les ressources de la carte mère. Le standard Plug and Play a été introduit pour limiter ces problèmes par la suite, mais ce n'est qu'avec l'arrivée des cartes PCI que l'on a enfin pu commencer à brancher n'importe quoi n'importe comment dans un ordinateur (cela dit, ce n'est pas encore la panacée parce que l'on est toujours obligé d'éteindre l'ordinateur...). Enfin, les cartes graphiques ne se connectent plus de nos jours ni sur les ports PCI, ni sur les ports ISA, pour des raisons de performances et de débit de données. Elles utilisent un port spécial, le port AGP. Cela ne pose cependant pas de problème de configuration spécial (du moins si l'on se contente d'une seule carte graphique).
Ce chapitre traite de la manière de configurer les cartes ISA et PCI en général, et donne des informations plus détaillées pour chacun des types courants de cartes filles.
L'architecture initiale des PC a très mal vieilli et souffre actuellement de défauts majeurs qui nuisent à leur développement. Sans parler des goulots d'étranglement sur les différents bus systèmes qui ne suivent plus les vitesses des processeurs actuels, la plupart des périphériques sont obligés de se restreindre à des protocoles de communication obsolètes pour conserver une compatibilité ascendante. L'une des limitations majeurs de cette architecture est le nombre incroyablement restreint de lignes d'interruption permettant à un périphérique de signaler au processeur qu'il a besoin de l'intervention de son gestionnaire pour poursuivre son travail, et la quasi absence des possibilités d'accès directs à la mémoire, qui impose l'utilisation du processeur pour réaliser de simples transferts de données entre les périphériques et la mémoire.
Ces ressources limitées, en plus de pénaliser les performances, posent des problèmes évidents d'extensibilité. En effet, qui dit ressource limité dit qu'il est impossible de connecter plus de périphériques « intelligents » que ce que l'architecture matérielle autorise. L'installation de plusieurs cartes ISA gérant chacune une interruption ou un canal DMA était réellement un casse-tête il y a encore peu de temps. C'est pour résoudre ces problèmes de configuration du matériel que le standard Plug and Play a été développé. Ce standard établit un protocole de communication matériel permettant au BIOS de configurer automatiquement les périphériques ISA en évitant les conflits sur les ressources partagées (le plus souvent, les lignes d'interruption).
Ce protocole a soulagé bien des gens, mais suppose un support spécifique de la part du système d'exploitation, puisque les paramètres matériels de chaque carte Plug and Play ne sont pas fixés d'un démarrage à l'autre de la machine. Il faut donc que le système soit ou capable de récupérer ces paramètres, ou de refaire la configuration du matériel. Cette deuxième solution est souvent imposée par le fait que bon nombre de BIOS sont bogués et effectuent une mauvaise configuration des cartes Plug and Play.
Le Plug and Play a été une amélioration sensible, mais n'a pas résolu les problèmes concernant les ressources limitées des PC. Heureusement, depuis l'avènement du bus PCI, ces limitations se sont estompées. En effet, le bus PCI permet non seulement aux périphériques de s'autoconfigurer et de se déclarer dans le système PCI, mais également de partager une même ligne d'interruption et de prendre le contrôle du bus mémoire. Ainsi, il n'y a virtuellement plus aucune difficulté pour installer une carte PCI dans un ordinateur (si vous avez le choix, prenez systématiquement des périphériques PCI). Ne croyez pas pour autant que le bus PCI soit idéal, c'est loin d'être le cas. En effet, il ne permet pas l'ajout et la suppression de cartes à chaud (c'est-à-dire lorsque le système est allumé), et fonctionne désormais à une vitesse bien trop faible compte tenu de la vitesse des processeurs, cartes graphiques et circuits mémoire. Il est donc appelé à disparaître sous peu lui-aussi.
Les périphériques PCI sont les plus courants actuellement. Le sous-système PCI de Linux permet de les utiliser directement, sans configuration particulière. Les périphériques ISA, en revanche, peuvent être plus difficiles à configurer. S'ils ne sont pas Plug and Play, il n'y a pas d'autre choix que de spécifier leurs paramètres matériels directement, soit lors de la compilation du noyau, soit à l'aide d'options de boot lorsque le système démarre, soit à l'aide d'options dans le fichier /etc/modules.conf si leur gestionnaire est compilé sous forme de module. La première solution est la plus technique, puisqu'elle nécessite de reconfigurer et de recompiler le noyau, les deux autres relèvent de la configuration simple.
Les cartes ISA Plug and Play constituent un cas à part car, comme il l'a été dit ci-dessus, la plupart des BIOS Plug and Play sont bogués et les initialisent mal. Il est donc nécessaire que le système les initialise lui-même, et détermine par la même occasion leur configuration matérielle. En pratique, il existe deux possibilités pour effectuer ces deux opérations. La première possibilité est de laisser le noyau faire tout le travail de configuration des cartes et d'allocation des ressources. La deuxième possibilité est d'effectuer la configuration des cartes ISA Plug and Play au niveau applicatif dans les scripts de démarrage du système. Cette solution est relativement technique, et ne doit être utilisée que lorsqu'on désire contrôler finement les ressources allouées par les périphériques dans le système.
Si l'on désire utiliser les fonctionnalités Plug and Play du noyau, il n'y a strictement rien à faire. Linux se charge simplement d'initialiser automatiquement les cartes ISA Plug and Play lors du démarrage du système, de leur attribuer les paramètres matériels adéquats, et de communiquer ces paramètres aux gestionnaires de périphériques. Il prendra également en charge la gestion des conflits avec les autres périphériques, qu'ils soient ISA non Plug and Play ou PCI. Par conséquent, vous n'aurez aucune configuration spécifique à effectuer.
Mais Linux fournit également la possibilité de contrôler soi-même les ressources allouées à chaque périphérique, pour ceux qui veulent avoir la maîtrise totale de leur matériel ou ceux qui ont une configuration tellement spécifique qu'elle nécessite un paramétrage manuel. Dans ce cas, l'initialisation des cartes ISA Plug and Play ne se fera pas lors du démarrage du noyau, mais plutôt ultérieurement. En général, on effectue cette tâche dans les scripts d'initialisation du système, mais ce n'est pas une obligation. Quoi qu'il en soit, comme l'attribution des ressources aux cartes est différée, les gestionnaires de périphériques ne peuvent pas être inclus dans le noyau. Il est donc nécessaire d'utiliser les modules du noyau pour ces gestionnaires. Les paramètres matériels pourront alors être communiqués simplement à ces gestionnaires lors du chargement des modules, à l'aide d'options dans le fichier de configuration /etc/modules.conf.
La configuration manuelle des cartes ISA Plug and Play se fait classiquement à l'aide des outils « isapnp ». Parmi ces outils se trouve le programme isapnp, que l'on utilise pour initialiser les cartes ISA Plug and Play. Cet utilitaire utilise les informations qui se trouvent écrite dans le fichier de configuration /etc/isapnp.conf pour déterminer les plages d'entrée/sortie, les canaux DMA et les lignes d'interruption à utiliser pour chaque carte.
La rédaction manuelle du fichier isapnp.conf n'est pas une tâche aisée. Heureusement, cela peut être réalisé automatiquement, à l'aide d'un autre utilitaire nommé pnpdump. Celui-ci affiche la liste des différentes possibilités de configuration pour chaque périphérique ISA Plug and Play. Cette liste est affichée exactement sous une forme exploitable par isapnp, ce qui fait qu'il est très simple de créer un fichier de configuration correct en faisant une redirection de sa sortie standard dans un fichier :
Le fichier de configuration ainsi créé contient les différentes configurations possibles. Cependant, elles sont toutes commentées, et aucun périphérique ISA ne sera configuré sans intervention supplémentaire. Il va donc falloir éditer ce fichier et retirer les commentaires devant les options de configuration qui vous intéressent. Les lignes de commentaires commencent toutes par un caractère dièse ('#'). Il suffit donc d'effacer ce caractère pour les décommenter. Vous devez choisir les options à décommenter de telle manière qu'aucun conflit d'adresse, d'interruption ou de canal DMA n'existe dans votre système. Pour chaque périphérique, plusieurs possibilités sont offertes, mais vous ne devez retirer les commentaires que devant les lignes d'une seule de ces possibilités. Les zones à décommenter sont clairement identifiées dans le fichier isapnp.conf généré par pnpdump, il vous suffit donc d'effectuer le choix de la configuration à utiliser. Enfin, il ne faut pas oublier de retirer le commentaire devant la ligne suivante :
(ACT Y)à la fin des différentes options de configuration pour chaque carte correctement configurée, faute de quoi elle ne sera pas activée lors de l'appel à isapnp.
En général, il est souhaitable d'appeler la commande isapnp à chaque démarrage du système, dans un des scripts de démarrage. Vous devrez donc inclure une ligne telle que celle-ci :
dans le fichier de démarrage principal de votre système. Ce fichier peut se trouver dans le répertoire /etc/rc.d/ (ou dans /sbin/init.d/ selon la distribution que vous utilisez). La plupart des distributions permettent de paramétrer l'appel à cette commande à l'aide d'une option de configuration modifiable à l'aide de leur programme de configuration. Consultez la documentation de votre distribution pour plus de détails à ce sujet.Une fois que vous aurez déterminé la configuration correcte pour vos périphériques dans le fichier /etc/isapnp.conf, vous pourrez charger les modules du noyau gérant ces périphériques. Cela peut nécessiter la modification du fichier /etc/modules.conf. Afin de limiter les risques d'erreur, vous devriez procéder comme suit :
déterminer le fichier spécial de périphérique utilisé par les applications pour accéder à votre périphérique ;
déterminer le nom du module que le noyau tentera de charger lorsqu'un programme tentera d'utiliser ce fichier spécial de périphérique ;
rechercher la ligne définissant l'alias pour ce nom de module, afin de savoir quel est le module qui sera effectivement chargé par modprobe. Vous pouvez également trouver ce nom dans la documentation de la configuration du noyau pour le gestionnaire du périphériques que vous configurez, ou en regardant directement dans le répertoire d'installation des modules /lib/modules/ ;
ajouter éventuellement la ligne « options module paramètres » permettant de spécifier les paramètres de chargement paramètres pour le module module ;
ajouter éventuellement les lignes « pre-install », « post-install », « pre-remove » et « post-remove » permettant d'effectuer des actions complémentaires avant et après le chargement du module, ainsi qu'avant et après son déchargement.
Comme il l'a été indiqué dans la Section 8.1.2, la détermination des noms de modules utilisés par le noyau pour les requêtes de chargement automatique n'est pas facile. Si vous utilisez le système de fichiers virtuel /dev/, ce nom est exactement le chemin complet du fichier spécial de périphérique. En revanche, si vous utilisez les fichiers spéciaux de périphériques classiques, vous aurez sans doute à vous servir du type, du code majeur et du code mineur de ce fichier spécial de périphérique. Vous pourrez obtenir ces informations à l'aide de la commande ls -l fichier, où fichier est le nom du fichier spécial de périphérique. Le type de ce fichier est indiqué dans le premier caractère des droits du fichiers. Le caractère 'c' indique que le périphérique est un périphérique de type caractère, et le caractère 'b' indique qu'il s'agit d'un périphérique de type bloc. Les numéros de codes majeur et mineur quant à eux sont indiqués juste après les informations concernant le propriétaire et le groupe du fichier, généralement égaux à « root » ;
Dans tous les cas, il est fortement recommandé de lire la documentation du module gérant votre périphérique Plug and Play. Cette documentation est en général située dans le répertoire /usr/src/linux/Documentation/.
Pour tester si les modifications que vous avez effectuées sont correctes, vous pouvez essayer de charger le module avec la commande suivante :
où module est le nom du module à charger. Vous pouvez également vérifier que ce module se charge bien lorsqu'une requête sur le fichier spécial de périphérique correspondant est effectuée, avec par exemple la commande suivante : où périphérique est le fichier spécial de périphérique à tester. Vous pouvez voir si le module s'est correctement chargé en demandant la liste des modules chargés à l'aide de la commande lsmod. Cette commande vous indique également l'état de chaque module, ainsi que le nombre de fois qu'il est utilisé et par qui. Si un module est marqué « uninitialized », vous avez de fortes chances de devoir redémarrer l'ordinateur et de revoir votre configuration, car un module qui se trouve dans cet état est inutilisable et peut parfois même refuser de se décharger.La plupart des cartes son vendues actuellement sont des cartes PCI, qui se configurent relativement aisément. Cependant, il existe encore un bon nombre de cartes son ISA, dont la configuration peut être plus technique, surtout si elles ne sont pas Plug and Play. De plus, les fonctionnalités fournies par les gestionnaires de son de Linux varient dans de larges proportions, selon le matériel utilisé. En particulier, toutes les cartes son ne sont pas capables de gérer la restitution des fichiers MIDI, et celles qui le gèrent nécessitent parfois une configuration particulière. Cependant, il est possible d'utiliser un convertisseur logiciel de fichiers MIDI en fichiers son classiques afin de jouer ce type de fichier même avec une carte son classique.
La première étape lors de la configuration de votre carte son sera la sélection du gestionnaire de périphériques à utiliser dans le programme de configuration du noyau. En ce qui concerne les cartes son, les options de configuration se trouvent dans le menu « Sound ». Ce menu permet de choisir les pilotes à utiliser en fonction du matériel installé. Ils sont classés en deux catégories : les pilotes classiques (première partie des options du menu) et les pilotes OSS (options du sous-menu « OSS sound modules »). OSS (« Open Sound System ») est une spécification d'interface de programmation permettant l'accès aux cartes son. Cette interface est en passe de devenir le standard dans le monde Unix. C'est un produit commercial, mais l'interface en soi est libre de droits et une implémentation libre en est fournie dans le noyau de Linux. Vous devez ici choisir le gestionnaire de périphériques qui convient le mieux à votre matériel. Si vous avez le choix entre les pilotes classiques et les pilotes OSS, choisissez les pilotes OSS car ils sont plus courants et vous n'aurez aucun problème à utiliser votre carte son avec la plupart des logiciels.
L'erreur la plus classique que l'on peut faire ici est de supposer que l'on possède une carte compatible Sound Blaster alors que ce n'en est pas une. Je tiens à préciser que quasiment aucune carte dite « compatible » sous Windows ne l'est sous Linux. La compatibilité sous Linux, c'est le fait d'avoir quasiment la même électronique ou du moins les mêmes interfaces au niveau matériel. Sous Windows, la compatibilité n'existe qu'au niveau des interfaces fournies par le pilote de la carte son. Par conséquent, il vous faut savoir exactement de quel nature est votre carte son, et non ce que vous avez retenu des arguments commerciaux du fabricant. Notez en particulier que certaines cartes Sound Blaster ne sont pas compatibles Sound Blaster (Creative Labs est renommé en ce qui concerne les incompatibilités entre les différents modèles de cartes son). C'est notamment le cas pour les cartes sons SB64 PCI et SB128 PCI, qui sont en réalité des cartes son ESS1370 ou ESS1371, et dont l'électronique est fabriquée par la société Ensoniq (cette société a été rachetée par Creative Labs, qui vend ces cartes en s'appuyant sur son image de marque et qui sème ainsi la confusion sur le marché). En conclusion, si vous ne voulez pas essayer plusieurs pilotes et recompiler le noyau jusqu'à ce que vous trouviez le bon, renseignez-vous bien sur la nature de votre carte son (si possible avant de l'acheter, au moins afin de savoir exactement ce que vous aurez). Vous pouvez également taper la commande lspci afin de voir les périphériques réellement présents sur le bus PCI. La commande système dmesg peut également vous être utile. Elle permet de réafficher la liste des messages générés par le noyau lors de son amorçage.
Lorsque vous aurez choisi le gestionnaire de périphériques adéquat, vous aurez le choix entre le compiler à l'intérieur du noyau (en choisissant l'option 'Y') ou le compiler sous forme de module (en choisissant l'option 'M'). En pratique, il est plus simple de compiler les gestionnaires de périphériques à l'intérieur du noyau pour les cartes PCI et les cartes ISA Plug and Play. En effet, Linux attribuera automatiquement les lignes d'interruptions, les ports d'entrée/sortie et les canaux d'accès direct à la mémoire pour ce type de matériel. Cette configuration n'est donc pas à faire, et votre carte son fonctionnera immédiatement.
C'est généralement également le bon choix pour les vielles cartes son ISA qui ne sont pas Plug and Play. En effet, pour ces cartes sons, la configuration logicielle est très simple, puisqu'on ne peut pas les configurer du tout. Bien entendu, il faut que vous ayez résolu manuellement les conflits possibles de matériel de votre ordinateur, mais cela ne concerne pas Linux. Pour ces cartes, il faut bien entendu indiquer au noyau les paramètres matériels (IRQ, DMA et ports d'entrée/sortie) lors de la configuration.
Il se peut toutefois que vous ne puissiez pas spécifier ces paramètres matériels dans les menus de configuration de Linux. Bien qu'en théorie il soit possible de modifier les fichiers sources de Linux directement pour indiquer ces paramètres, ce n'est pas à la portée du commun des mortels. Par conséquent, on utilisera les modules du noyau, et les options matérielles seront indiquées dans le fichier de configuration /etc/modules.conf. Notez que c'est également de cette manière que vous devrez procéder si vous désirez configurer vous-même l'allocation des ressources pour les cartes son ISA Plug and Play, ou, autrement dit, si vous préférez utiliser l'outil isapnp au lieu des fonctionnalités Plug and Play du noyau.
Ces opérations vous permettront de faire fonctionner votre carte son pour toutes les opérations de base, à savoir la lecture et l'enregistrement de fichiers son, le réglage du volume sonore et éventuellement la lecture des CD audio par l'intermédiaire de votre carte son (si, bien entendu, vous avez relié la sortie audio de votre lecteur de CD à l'entrée auxiliaire de votre carte son). Vous ne pourrez cependant pas lire les fichiers MIDI sans réaliser les opérations décrites ci-dessous.
Les fichiers MIDI sont des fichiers ne contenant que les « partitions » des morceaux enregistrés. Ils ne contiennent pas les données audio numériques comme c'est le cas pour les fichiers son classiques ou les pistes de CD audio. Cela explique leur taille réduite, mais pose un problème pour leur restitution. En effet, la lecture d'un fichier MIDI suppose que votre carte son dispose d'un jeu de sons numérisés dans sa mémoire afin de pouvoir reconstituer le signal sonore à partir des informations du fichier MIDI. Ces sons sont couramment appelés des « patches », et ils peuvent être enregistrés soit en dur dans la mémoire de la carte son, soit chargés lors de son initialisation. Il va de soi que certaines cartes son ne disposent pas des fonctionnalités nécessaires à la lecture des fichiers MIDI. Dans ce cas, il faut utiliser un programme externe capable de synthétiser le son à partir de patches enregistrés sur le disque dur et d'envoyer les données audio ainsi créées à la carte son pour la lecture.
Pour les cartes son qui ne disposent pas des patches en mémoire morte, il est nécessaire d'utiliser un programme afin de les charger dans la mémoire de la carte. Il va de soi que ce programme est spécifique à la carte son et doit être installé. Par exemple, pour les cartes Sound Blaster AWE, ce programme se nomme sfxload. Ce programme peut être trouvé soit sur le site de Creative Labs, soit à http://members.tripod.de/iwai/awedrv.html. Vous trouverez également les fichiers de patches utilisables avec les cartes son AWE sur ce site. Vous pouvez utiliser le fichier de définition des patches de Creative, que vous trouverez normalement soit sur une installation de Windows avec une carte son AWE, soit sur vos CD d'installation, soit sur Internet. Le fichier fourni par Creative se nomme synthgm.sbk.
Pour charger les patches dans la mémoire de la carte, il suffit d'utiliser la commande suivante :
(en supposant que le fichier de patches soit placé dans le répertoire /usr/lib/). Vous pourrez placer cette commande dans les scripts de démarrage de votre système ou dans une option de chargement du module awe_wave qui gère la lecture des fichiers midi. Vous trouverez ci-dessous un exemple d'options du fichier /etc/conf.modules permettant le chargement correct des modules d'une carte son Sound Blaster AWE :# Chargement des modules de son : alias char-major-14 sb options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 options adlib_card io=0x388 # Chargement automatique du module de lecture des fichiers MIDI : post-install sb /sbin/modprobe -k midi alias midi awe_wave # Chargement des patches en mémoire : post-install awe_wave /usr/local/bin/sfxload /usr/lib/synthgm.sbk
Pour les cartes son ne disposant pas de la possibilité de lire les fichiers MIDI, il ne reste que la solution de l'émulation logicielle. Vous pourrez dans ce cas recourir au programme nommé « Timidity ». Timidity est un programme de lecture de fichiers MIDI très complet, paramétrable et capable d'utiliser des banques de son externes variées. De plus, le moteur de Timidity est utilisé par de nombreux autres programmes, en particulier par le lecteur KMidi de KDE.
L'auteur originel de Timidity ne le maintient plus. Cependant, d'autres programmeurs ont pris le relais et l'ont amélioré pour en faire la version Timidity++. Cette dernière version peut être trouvée sur Internet sur le site de Timidity. L'archive que vous récupérerez ne contient pas forcément le programme : il peut ne s'agir que des fichiers sources permettant de le générer. Les notions de fichiers sources et de compilation de programmes exécutables seront expliquées en détail dans le chapitre suivant. En attendant, si vous récupérez les sources, vous pourrez suivre les indications données ci-dessous pour compiler et installer Timidity.
Timidity peut utiliser différentes interfaces utilisateur, accessibles via différentes bibliothèques. Il est recommandé d'utiliser l'interface Tcl/Tk, car cette interface fonctionne aussi bien sous XWindow qu'en mode texte. Pour cela, il suffit de configurer les sources avec la ligne de commande suivante :
Une fois cela fait, vous pourrez générer l'exécutable avec la commande suivante :
et l'installer avec la commande :Cela installera Timidity dans le répertoire /usr/local/bin/.
La deuxième étape est bien entendu d'installer les fichiers de patches. Timidity utilise des patches pour les cartes son Gravis Ultrasound. Vous pourrez trouver des archives contenant de tels patches sur Internet très facilement. En particulier, la collection de patches EAWPATS réalisée par Eric A. Welsh est très complète, quoiqu'un peu grosse pour un téléchargement. Cette collection a de plus l'avantage d'être préconfigurée pour l'emploi avec Timidity.
Lorsque vous aurez installé les fichiers de patches, vous devrez indiquer à Timidity leur emplacement dans le système de fichiers. Cette information doit être stockée dans le fichier de configuration timidity.cfg du répertoire /usr/local/share/timidity/. Vous pourrez vous inspirer du fichier fourni avec la collection de patches EAWPATS. Cependant, vous aurez à modifier les chemins indiqués dans ce fichier, car il a été écrit pour la version Windows de Timidity. Le premier répertoire à indiquer est celui des bibliothèques. Il faut ici simplement remplacer la ligne « dir c:\timidity » par la ligne « dir /usr/local/lib/timidity ». Notez que cette ligne est facultative et peut être commentée si vous n'avez pas déplacé ce répertoire. Le deuxième répertoire est plus important, puisque c'est le répertoire d'installation des patches. Il s'agit cette fois de remplacer la ligne « dir c:\eawpats » par la ligne « dir répertoire », où répertoire est le répertoire où vous avez extrait les fichiers patches.
Une fois que vous aurez terminé ces modifications, vous pourrez lire un fichier MIDI simplement en utilisant la ligne de commande suivante :
où fichier est le nom du fichier MIDI à lire. Si vous désirez utiliser l'interface graphique de Timidity, vous n'avez qu'à ajouter l'option -ik à la ligne de commande précédente.L'installation de KMidi ne pose pas de problème particulier, puisqu'il est fourni avec KDE et que KDE est normalement inclus dans toute bonne distribution. La seule opération que vous ayez à faire est simplement de modifier le fichier de configuration de KMidi pour lui indiquer l'emplacement des fichiers de patches. Or comme KMidi est basé sur les sources de Timidity, il utilise le même fichier de configuration timidity.cfg que Timidity. Ce fichier est normalement situé dans le répertoire /base/kde/share/apps/kmidi/config/, où base représente le répertoire de base d'installation de KDE. Vous n'aurez donc qu'à répéter les opérations faites sur le fichier de configuration de Timidity avec le fichier de configuration de KMidi.
De nos jours, toutes les cartes graphiques disposent d'une accélération matérielle non seulement pour les opérations graphiques en 2D, mais également pour le calcul de scènes en 3D. Ce développement des cartes 3D a été principalement poussé pour les jeux, mais ces fonctionnalités sont également très utiles pour les applications de modélisation et de conception.
La manière dont les opérations graphiques en 3D sont réalisées dépend évidemment du modèle de carte graphique utilisée, car il n'existe pas de standard au niveau matériel. Comme il est impensable que les applications qui désirent utiliser les fonctionnalités 3D des ordinateurs modernes aient à prendre en compte le type de carte utilisée, des interface logicielles standards ont été définies.
De toutes ces interfaces, Linux n'en gère qu'une seule : OpenGL. Cette interface a été définie par Silicon Graphics pour ses stations de travail haut-de-gamme et s'est imposée comme étant la norme en la matière pour ce qui est de la 3D. Cette interface a l'avantage d'être ouverte et disponible sur la plupart des systèmes, qu'ils soient de type Unix ou non.
La prise en charge de l'interface OpenGL est réalisée en deux endroits sous Linux. La partie principale réside dans le serveur X qui, comme nous l'avons déjà signalé, n'est rien d'autre que le programme fournissant les services graphiques aux autres applications sous Unix. Cette partie est implémentée par une extension de l'interface de programmation XWindow, que l'on nomme tout simplement GLX. Cependant, le serveur X ne peut pas tout faire à lui tout seul car, pour des raisons de performances, il lui faut accéder directement au matériel lors du rendu de scènes 3D. Il s'appuie donc pour cela sur un module du noyau, dont le but est de contrôler les accès au ressources matérielles et de garantir ainsi la stabilité globale du système.
La configuration des fonctionnalités 3D des cartes graphiques sous Linux nécessite donc d'intervenir à la fois dans le noyau et au niveau du serveur X. Pour ce qui est du noyau, il faut tout d'abord s'assurer que les fonctionnalités d'accès direct au matériel sont bien supportées. Ces fonctionnalités sont couramment appelées « DRI », ce qui est l'abréviation de l'anglais « Direct Rendering Infrastructure ». Pour activer les fonctionnalités DRI, vous devrez, dans la configuration du noyau, valider l'option « Direct Rendering Manager » du menu « Character devices », ainsi que le type de carte graphique utilisée (3Dfx, 3dlabs, ATI Rage 128 ou ATI Radeon, chipset i810 ou Matrox G200/G400).
Note : Les fonctionnalités 3D des cartes graphiques basées sur les puces NVidia ne sont pas supportées directement par XFree86 et par le noyau. En revanche, NVidia fournit un pilote pour Linux pour ces cartes, qui, bien qu'il n'utilise pas DRI, dispose également d'un module du noyau et d'un module pour XFree86.
Quelle que soit votre carte graphique, vous aurez également sans doute intérêt à activer le support du bus AGP dans le noyau, si bien sûr votre carte graphique est une carte AGP. Pour cela, il suffit d'activer l'option « /dev/agpgart (AGP support) » dans le menu « Character devices » de la configuration du noyau, ainsi que le type de chipset utilisé par votre carte mère.
Une fois la configuration du noyau faite, vous pourrez le recompiler et l'installer. La manière de procéder a été décrite en détail dans la Section 7.3.
Vous devrez également vous assurer que le fichier spécial de périphérique /dev/agpgart est bien présent dans le répertoire /dev/. Son code majeur est 10, et son code mineur est 175. De même, si vous avez compilé les options précédentes sous la forme de modules du noyau, assurez-vous qu'ils sont bien référencés dans le fichier modules.conf.
La suite des opérations se passe alors au niveau de la configuration du serveur X de XFree86. L'activation du support de l'AGP et d'OpenGL se fait simplement en rajoutant deux options dans le fichier de configuration /etc/X11/XF86Config. Vous devez trouver la section « Modules » et lui ajouter les deux lignes suivantes :
Section "Module"
⋮
Load "dri"
Load "glx"
⋮
EndSection
Vous trouverez de plus amples renseignements sur la manière de procéder dans le Chapitre 10.
Note : Pour le pilote fourni par NVidia pour XFree86, il n'est pas nécessaire de demander le chargement du module DRI, car il ne l'utilise pas.
Il est supposé ici que le serveur X utilisé correspond bien à la carte graphique et dispose des fonctionnalités 3D. Si ce n'est pas le cas, vous devrez sans doute réinstaller XFree86.
Les programmes utilisant OpenGL utilisent souvent une bibliothèque complémentaire nommée GLUT. Cette bibliothèque est fournie avec la couche d'émulation logicielle d'OpenGL MESA. Bien que MESA soit distribuée en standard avec XFree86, la bibliothèque GLUT n'est disponible que dans les programmes d'exemples de MESA. Vous devrez donc réinstaller MESA complètement si votre distribution ne fournit pas la bibliothèque GLUT avec XFree86.
Linux fournit toutes les fonctionnalités nécessaires à la manipulation des flux de données vidéo par l'intermédiaire d'une interface de programmation nommée video4linux (ce qui se lit « Video for Linux »). Linux est capable de gérer la plupart des cartes d'acquisition TV du marché et quelques-unes des cartes d'acquisition vidéo. Comme d'habitude, seuls les constructeurs de matériel qui ont accepté de jouer le jeu de fournir les informations nécessaires à la programmation de gestionnaires de périphériques libres voient leur matériel supporté sous Linux. Par conséquent, il est encore une fois nécessaire de bien se renseigner sur la nature du produit et la politique du fabricant lorsqu'on achète une carte d'acquisition TV.
En pratique, quasiment toutes les cartes d'acquisition TV utilisent le circuit intégré Bt848 ou un de ses dérivés, et Linux sait les gérer sans problèmes. Les cartes d'acquisition et de montage vidéo utilisent d'autres circuits plus puissants, dont les spécifications sont généralement non disponibles. Seule la configuration des cartes TV sera donc décrite ci-dessous.
Les applications, pour accéder aux périphériques vidéo, utilisent l'un des fichiers spéciaux de périphérique /dev/video*. Ces fichiers sont des fichiers de type caractère, dont le code majeur vaut 81. Le code mineur est utilisé pour différencier les différents périphériques installés sur votre système. En général, il existe un lien symbolique /dev/video sur l'un de ces fichiers spéciaux, qui sera utilisé pour accéder au périphérique vidéo par défaut. Normalement, tous ces fichiers sont installés d'office dans le répertoire /dev/ par les distributions, et vous n'aurez pas à les créer vous-même.
Le support de la vidéo sous Linux passe bien entendu par la configuration du noyau. Cette fois, il n'est pas certain du tout que le noyau fourni avec votre distribution supporte les cartes d'acquisition TV, aussi aurez-vous peut-être à recompiler vous-même votre noyau. La manière de procéder a été décrite en détail dans la Section 7.3.
Sachez toutefois que les options à valider dans la configuration du noyau se trouvent dans le menu « Multimedia devices ». Vous devrez activer l'option « Video For Linux » sous la forme de module, car vous aurez sans doute à communiquer des paramètres aux modules vidéo afin de leur spécifier le type de carte utilisé et le type de tuner. Le module qui sera créé portera le nom videodev, c'est celui qui se chargera de répondre aux requêtes du client sur les fichiers spéciaux de périphérique /dev/video*. Lorsque vous aurez activé la fonctionnalité de vidéo pour Linux, vous aurez le choix des pilotes de cartes vidéo dans le sous-menu « Video adapters ».
Note : La configuration des cartes basées sur la puce Bt848 (option de menu « BT848 Video For Linux ») n'est accessible que si vous avez également activé l'option « I2C bit-banging interfaces » du menu « I2C support ». De même, le module prenant en charge les puces du type Bt848 ne prend pas en charge la gestion du son. En revanche, vous pourrez trouver le gestionnaire du son de ces cartes avec les autres gestionnaires de cartes son, dans le menu « Sound ». L'option que vous devez activer est l'option « TV card (bt848) mixer support ».
Une fois le noyau recompilé et les nouveaux modules installés, il faut modifier le fichier de configuration /etc/modules.conf. Bien que Linux soit parfaitement capable de déterminer les ressources requises par les cartes vidéo, il est rare que le matériel soit correctement identifié par les gestionnaires de périphériques vidéo. En effet, ces gestionnaires se basent plus sur les composants courants permettant de faire l'acquisition vidéo que sur les modèles de cartes de chaque fabricant. La palme revient sans doute au gestionnaire pour les cartes basées sur les puces Bt848 et ses dérivées, puisqu'il est capable de faire fonctionner toutes les cartes vidéo de tous les fabricants qui utilisent cette puce. Par conséquent, il faut indiquer le modèle de la carte au gestionnaire, à l'aide des options des modules vidéo dans le fichier modules.conf.
En fait, le gestionnaire pour les cartes basées sur la puce Bt848 est constitué de deux modules. Le premier, nommé bttv, gère la puce Bt848 elle-même et prend en charge les flux vidéo et l'incrustation vidéo dans la mémoire de la carte graphique. Le deuxième module quant à lui s'occupe de la gestion de la puce du tuner, qui effectue la recherche des chaînes et le décodage des signaux vidéo. Pour ces deux modules, il est indispensable de préciser quelle type de carte TV est installé et quel tuner cette carte utilise. Il existe de nombreuses variantes, selon les modèles et les différents fabricants présents sur le marché.
Le type de carte peut être communiqué au module bttv à l'aide de l'option card. Cette option peut prendre comme valeur un numéro identifiant le modèle de la carte. Les valeurs actuellement supportées sont indiquées dans le fichier CARDLIST du répertoire /usr/src/linux/Documentation/video4linux/bttv/.
Le module de gestion du tuner utilise l'option type pour déterminer le type de tuner utilisé. Cette option prend, elle aussi, une valeur numérique indiquant la nature du tuner utilisé. Les valeurs supportées sont également données dans le fichier CARDLIST. En pratique, il est fort probable que vous utilisiez le type 3, qui correspond au tuner Philips SECAM, car la France utilise le standard SECAM pour les émissions TV.
Ainsi, si vous disposez d'une carte MIRO PCTV (carte de type 1) basée sur le tuner Philips SECAM, vous devriez avoir les lignes suivantes dans votre fichier modules.conf :
# Lien entre les fichiers spéciaux de périphériques et les modules du noyau : alias char-major-81 videodev alias char-major-81-0 bttv # Options du module de gestion du Bt848 : options bttv card=1 # Option du module de gestion du tuner : options tuner type=3
Note : Si vous avez compilé les fonctionnalités de l'interface I2C sous forme de module (option de menu « I2C bit-banging interfaces »), vous aurez également à ajouter ces lignes dans votre fichier de configuration modules.conf :
Pour information, I2C est un protocole de communication entre micro-contrôleurs, que la plupart des cartes mères sont capables de gérer. Cette fonctionnalité n'est nécessaire que pour les cartes basées sur la puce Bt848.
Lorsque vous aurez fini vos modifications dans le fichier de configuration modules.conf, n'oubliez pas d'appeler la commande depmod -a pour remettre à jour les dépendances entre les modules du noyau. Si tout se passe bien, vous pourrez utiliser les programmes de lecture TV, comme KWinTV par exemple si vous utilisez l'environnement de bureau KDE.
Note : Vous pouvez rencontrer quelques problèmes lors de la configuration de votre carte TV. Généralement, si vous n'obtenez aucune image, c'est que vous vous êtes trompé de tuner. Revoyez dans ce cas l'option type du module tuner. Si vous obtenez bien une image, mais pas de son, c'est sans doute que vous vous êtes trompé dans le type de carte, ou que vous avez oublié d'inclure le support du son pour les cartes à base de Bt848. On notera que, comme pour les cartes son, seule la compatibilité matérielle importe. Par exemple, les cartes Studio PCTV de Pinacle vendues en France sont en réalité des cartes Miro PCTV et ne sont pas reconnues comme des cartes Studio PCTV par Linux... Si vous avez des problèmes de son, vous devrez donc revoir la configuration du noyau ou modifier la valeur passée à l'option card du module bttv. Dans tous les cas, n'hésitez pas à utiliser la commande lspci, qui permet de visualiser les informations du bus PCI, et la commande dmesg, qui permet de voir la liste des messages du noyau.
Vous pouvez également avoir quelques problèmes de droits sur les fichiers spéciaux de périphériques /dev/videoX. Le symptôme classique est dans ce cas que tout fonctionne parfaitement sous le compte root, mais pas sous les comptes utilisateurs. Dans ce cas, on pourra résoudre ces problèmes en créant un groupe d'utilisateurs video, auquel appartiendront tous les utilisateurs ayant le droit d'utiliser la carte d'acquisition TV, et de changer le groupe des fichiers spéciaux de périphériques /dev/videoX.
Enfin, l'utilisation des cartes d'acquisition TV nécessite d'activer les fonctionnalités DGA du serveur X. Ces fonctionnalités permettent aux programmes d'accéder directement à la mémoire vidéo, et donc de faire l'incrustation de l'image décodée par la carte TV dans la surface d'affichage d'un écran. La manière d'activer les fonctionnalités DGA sera précisée dans le chapitre traitant de la configuration du serveur X.
Le support des cartes réseau est très complet sous Linux et la prise en charge d'une nouvelle carte revient souvent simplement à ajouter le gestionnaire de périphériques de cette carte dans la configuration du noyau. La plupart des cartes réseau sont des cartes Ethernet compatibles soit avec les cartes NE2000, soit avec les cartes 3COM, aussi suffit-il en général d'activer le gestionnaire de périphériques pour l'une de ces cartes pour qu'elle soit utilisable.
La configuration des gestionnaires de périphériques se fait dans le menu « Network device support » de la configuration du noyau. Il faut activer l'option « Network device support » en premier lieu, puis sélectionner le gestionnaire de périphériques approprié dans le sous-menu « Ethernet (10 or 100Mbit) ». Ce menu présente en premier lieu les gestionnaires de périphériques pour les cartes ISA, et regroupe les gestionnaires de toutes les autres cartes dans les sous-options de l'option « EISA, VLB, PCI and on board controllers (NEW) ». Vous aurez donc certainement à activer cette option et la sous-option correspondante au gestionnaire de périphériques de votre carte réseau. Vous pouvez activer ces options sous la forme de module du noyau ou non, le plus simple étant ici de ne pas utiliser les modules afin d'avoir à éviter de compléter le fichier de configuration /etc/modules.conf.
La compilation du noyau elle-même a été décrite en détail dans la Section 7.3 et ne sera donc pas reprise plus en détail ici. Remarquez également que la prise en charge de la carte réseau par un gestionnaire de périphériques ne suffit en aucun cas à l'utilisation de l'ordinateur en réseau. En effet, il faut également configurer l'ensemble des paramètres réseau du système, ce qui sera décrit dans le Chapitre 9. Le nombre des fonctionnalités réseau de Linux interdit de les décrire toutes ici, veuillez vous référer à ce chapitre pour plus de détails.
| Précédent | Sommaire | Suivant |
| Configuration des périphériques de masse | Niveau supérieur | Configuration des ports de communication |