| 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. De nos jour, on ne trouve quasiment plus de cartes ISA, et la plupart des cartes mères n'acceptent même plus ces cartes.
Mais 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 encore 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 encore appelé à évoluer.
Le sous-système PCI de Linux permet d'utiliser directement les cartes PCI, 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/modprobe.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/modprobe.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/modprobe.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 « install » et « remove », permettant d'effectuer des actions complémentaires lors du chargement et du déchargement du module.
Comme il l'a été indiqué dans la Section 8.1.1, la détermination des noms de modules utilisés par le noyau pour les requêtes de chargement automatique n'est pas facile. 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 ».
Quoi qu'il en soit, 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.Les fonctionnalités fournies par les gestionnaires de son de Linux varient dans de larges proportions, selon le matériel utilisé. La quasi totalité des cartes son gèrent bien entendu l'essentiel : la restitution de fichiers audio numériques. Les fonctionnalités des cartes son sont à ce niveau relativement disparates : les différences vont du taux d'échantillonage utilisé jusqu'à la possibilité de les faire fonctionner en full duplex (enregistrement et lecture simultanée) ou non. Cette dernière fonctionnalité est essentielle pour les applications de téléphonie sur Internet par exemple.
De plus, très peu de cartes son sont capables de gérer la restitution des fichiers MIDI correctement (les fichiers MIDI sont des fichiers musicaux permettant de stocker les séquences de notes à jouer pour restituer le morceau, au lieu de stocker le son lui-même sous forme numérique). La plupart des cartes son ne fournissent aucun support matériel pour cela, et la restitution des notes des fichiers MIDI se fait généralement à l'aide d'un synthétiseur logiciel. C'est en particulier le cas pour toutes les cartes son intégrées sur les cartes mères des ordinateurs récents. Les gestionnaires de périphériques de Linux ne fournissent pas de synthétiseur logiciel, en revanche il existe plusieurs programmes permettant de lire les fichiers MIDI, moyennant une consommation plus ou moins importante des ressources de calcul de l'ordinateur.
La plupart des cartes son bas de gamme disposent toutefois d'un synthétiseur en modulation de fréquence (synthétiseur dit « FM »), qui permet de simuler des notes d'instrument de musique, généralement avec une qualité très médiocre. Certains pilotes de cartes son de Linux permettent d'utiliser ces synthétiseurs, mais ce n'est toujours pas la panacée. En réalité, si l'on veut restituer correctement les notes des fichiers MIDI, il faut utiliser une carte son disposant de ce que l'on appelle une table d'échantillons. Ces tables permettent de stocker dans la mémoire de la carte son des échantillons de sons d'instruments de musique enregistrés en qualité numérique. La carte son peut ainsi reconstituer le son de toutes les notes de musique fidèlement, avec une très grande ressemblance avec l'instrument réel. Ces cartes sont bien entendu plus coûteuses, mais la qualité sonore est incomparable à ce niveau (les cartes SoundBlaster AWE et Live en particulier disposent de tables d'échantillons). Linux permet parfaitement d'utiliser ces cartes, et même de charger de nouveaux jeux d'échantillons dans la mémoire de la carte pour changer la sonorité des instruments.
Je ne saurais donc que trop vous conseiller de bien vous renseigner avant l'achat d'une carte son, car ce sujet n'est pas très souvent pris en considération lors de l'achat. Bien entendu, si vous ne désirez pas utiliser votre carte son dans ses derniers retranchements, vous pouvez vous contenter des cartes intégrées sur les cartes mères. Dans les autres cas, renseignez-vous.
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.
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 ». Vous y trouverez deux jeux de pilotes : les pilotes ALSA (« Advanced Sound Linux Architecture ») et les pilotes OSS (« Open Sound System »). Les pilotes ALSA sont les plus modernes, et devront être utilisés en priorité, car ils fournissent le plus de fonctionnalités. Les pilotes OSS sont des pilotes plus anciens, qui sont toutefois maintenus à titre de compatibilité d'une part et, d'autre part, parce que certaines cartes son ne sont pas encore totalement prises en charge par les pilotes ALSA. Les pilotes OSS sont eux-mêmes classés en deux catégories : les pilotes classiques (première partie des options du menu) et les pilotes OSS purs. Ces derniers utilisent une spécification d'interface de programmation commune permettant l'accès aux cartes son, mais il n'y a pas de différence au niveau des applications pour l'utilisation de ces pilotes. Vous devez choisir le gestionnaire de périphériques ALSA ou OSS qui convient le mieux à votre matériel.
L'erreur la plus classique que l'on peut faire au niveau du choix du pilote 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 de traces générés par le noyau, et vous y trouverez donc les messages relatif à la phase de détection des périphériques.
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'). Il est possible soit de charger ces pilotes en tant que module, soit de les intégrer au noyau. En général, il est préférable d'utiliser les modules, car les programmes de configuration audio peuvent ainsi détecter automatiquement les cartes son utilisées. De plus, certaines fonctionnalités non essentielles sont souvent désactivées par défaut par les pilotes, et doivent être activées explicitement à l'aide d'une option lors du chargement du module ou d'un paramètre à fournir au noyau lors de son amorçage. Les modules sont donc là aussi plus faciles à utiliser, car ils éviteront de redémarrer le système à chaque essai. Cependant, pour la plupart des paramètres matériels (en particulier les lignes d'interruptions, les ports d'entrée/sortie et les canaux d'accès direct à la mémoire), Linux déterminera automatiquement les valeurs correctes. Cette configuration n'est donc pas à faire, et votre carte son fonctionnera généralement immédiatement.
Les vielles cartes son ISA qui ne sont pas Plug and Play devront généralement également être intégrées au noyau. En effet, pour ces cartes sons, la configuration logicielle est très simple, puisqu'on ne peut pas les configurer du tout, et l'on n'a donc pas besoin de modules du tout. Bien entendu, il faut que vous ayez résolu manuellement les conflits possibles de matériel de votre ordinateur en fixant les switchs adéquats sur vos cartes filles, mais cela ne concerne pas Linux. Pour ces cartes, il faut généralement 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 malgré tout dans ce cas les modules du noyau, et les options matérielles seront indiquées dans le fichier de configuration /etc/modprobe.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.
Si vous compilez les gestionnaires de son sous la forme de modules, vous devrez ajouter les alias et les options nécessaires à leur chargement dans le fichier /etc/modprobe.conf.
Les fichiers spéciaux de périphériques utilisés ne sont pas les mêmes pour les pilotes OSS et les pilotes ALSA. Les premiers utilisent les fichiers spéciaux /dev/audio?, /dev/dsp? et /dev/mixer?, dont le numéro de code majeur est 14, alors que les seconds utilisent les fichiers spéciaux de périphériques /dev/aloadCn et /dev/aloadSEQ, ainsi que tous les fichiers spéciaux de périphérique du répertoire /dev/snd/, tous de numéro de code majeur 116. Les pilotes ALSA étant également capables de simuler le comportement des pilotes OSS par compatibilité, ils utilisent le numéro de code majeur 14 également.
Lorsque le noyau désire accéder aux fonctionnalités d'ALSA ou d'OSS, il cherche donc à charger, selon les fichiers spéciaux de périphériques utilisés, les modules char-major-116 ou char-major-14. Le premier doit être associé au module snd d'ALSA, alors que le second doit être associé au module soundcore. Ces modules prennent en charge respectivement les systèmes de son d'ALSA et d'OSS. Le fichier /etc/modprobe.conf devra donc définir ces alias comme suit :
# Permet le chargement des pilotes ALSA : alias char-major-116 snd # Permet le chargement des pilotes OSS ou l'émulation des pilotes OSS par ALSA : alias char-major-14 soundcore
Les systèmes de son gérés par ces modules permettent de prendre en charge plusieurs cartes son. Chaque carte son est bien entendu référencée par le numéro de code mineur du fichier spécial de périphérique utilisé. Il faut donc définir, pour chaque carte son, le module du gestionnaire de périphérique de cette carte son. Cela se fait en définissant les alias pour les noms de modules génériques snd-card-n pour ALSA et sound-slot-n pour OSS, où 'n' est le numéro de la carte son.
Par exemple, si l'on dispose d'une carte son SoundBlaster 128 avec les pilotes ALSA, le module à utiliser est snd-ens1370 ou snd-ens1371 selon le modèle (parce que ces cartes son sont en réalité des cartes Ensoniq). Le fichier de configuration /etc/modprobe.conf devra donc contenir les alias suivants :
# La première carte son est gérée par le module snd-ens1371 : alias snd-card-0 snd-ens1371 alias sound-slot-0 snd-card-0
Les modules des gestionnaires de périphériques peuvent prendre des options permettant de contrôler les ressources matérielles et les fonctionnalités prises en charge. Vous pourrez trouver la liste des différents modules de pilotes de périphériques disponibles, ainsi que leurs options, dans la documentation fournie dans le répertoire Documentation/sound/ des sources du noyau.
Enfin, les pilotes de périphériques OSS n'implémentent pas forcément l'ensemble des fonctionnalités classiques des cartes son. Lorsqu'une de ces fonctionnalité est demandée, le pilote peut donc demander le chargement d'un module complémentaire. Le nom utilisé par le noyau pour ce module est « sound-service-n-m », où 'n' est le code majeur du fichier spécial de périphérique de la carte son et m le code de la fonctionnalité utilisée. Ces codes correspondent aux numéros de codes mineurs des fichiers spéciaux de périphériques permettant d'accéder à ces fonctionnalités. Ainsi, la valeur 0 correspond au mixeur (fichier spécial de périphérique /dev/mixer), la valeur 2 correspond au port MIDI (fichier spécial de périphérique /dev/midi), et les codes 3 et 4 au canal de la carte son (fichiers spéciaux de périphériques /dev/dsp et /dev/audio). La liste des fichiers spéciaux de périphériques utilisés par OSS peut être consultée dans le fichier Documentation/devices.txt.
Si vous utilisez les pilotes ALSA, vous devrez ajouter les alias suivants dans le fichier /etc/modprobe.conf afin de charger à la demande les modules d'émulation des services OSS :
# Charge les modules ALSA des services OSS : alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss
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).
Le réglage des paramètres de votre carte son peut être réalisé très simplement si vous utilisez les pilotes ALSA. En effet, il existe une application en mode texte permettant de réaliser ces réglages. Cette application se lance simplement avec la commande alsamixer
Comme vous pouvez le constater, cette application présente une interface très simple, dans laquelle chaque canal de la carte son peut être réglé indépendamment. Pour passer d'un canal à l'autre, il suffit d'utiliser les flèches droite et gauche, et pour régler les volumes, d'utiliser les flèches haut et bas du clavier. Vous pouvez également rendre un canal complètement muet en appuyant sur la touche 'M'. Cette touche permet également d'activer ou de désactiver certaines fonctionnalités de votre carte son. Lorsque les réglages vous conviendront, vous pouvez simplement quitter alsamixer en appuyant sur la touche 'Échap'.
Les réglages réalisés de cette manière ne sont pas permanents.
Cela signifie que d'un redémarrage à l'autre de la machine, les valeurs par défaut seront reprises.
ALSA fournit donc également l'outil alsactl, qui permet d'enregistrer les paramètres
des cartes son dans le fichier de configuration /etc/asound.conf. Pour cela, il suffit
simplement d'appeler cette commande avec l'option store :
alsactl permet également de restaurer
les paramètres sauvegardés, à l'aide de son option restore. On aura donc tout
intérêt à placer une ligne telle que celle-ci dans les fichiers d'initialisation de sa distribution,
si ce n'est déjà fait :
Par ailleurs, pour les cartes son qui disposent
d'un synthétiseur FM, il peut être intéressant d'activer cette fonctionnalité. Généralement, les pilotes
ALSA désactivent cette fonctionnalité. Elle peut toutefois être réactivée en spécifiant le port
d'entrée / sortie du synthétiseur FM de la carte son à l'aide de l'option fm_port.
du module prenant en charge votre carte son. De même, vous pourrez activer la gestion des pilotes
MIDI en ajoutant l'option mpu_port et en indiquant le numéro de port pour
le port MIDI. Vous pouvez consulter le fichier de documentation
Documentation/sound/alsa/ALSA-Configuration.txt des sources du noyau Linux
pour plus d'informations à ce sujet. En général, le numéro de port utilisé pour les synthétiseurs FM
est le numéro 0x388, et le numéro du port MIDI est le 0x300. Par exemple, pour une carte son CMI,
la ligne suivante pourra être ajoutée dans le ficher de configuration
modprobe.conf :
Si vous désirez compiler en dur le pilote de votre carte son, vous devrez fournir ces informations en ligne de commande à l'amorçage du noyau. Vous devez donc ajouter, pour chacun de ces paramètres, une option à la ligne de commande du noyau. Par exemple, pour une carte son CMI, il faudrait ajouter les options suivantes dans le fichier de configuration du GRUB ou dans le fichier lilo.conf :
La première option permet d'indiquer que cette carte son est la première carte son du système. Elle peut être nécessaire si vous avez intégré dans le noyau des pilotes pour d'autres cartes son, réelles ou virtuelles. Les autres options sont directement déduites de celles spécifiées dans le fichier modprobe.conf.Enfin, vous aurez sans doute à charger une banque de sons dans le pilote, que vous utilisiez une synthèse FM ou une table d'échantillons. La manière de procéder est toutefois différente selon la carte son utilisée. Pour les cartes sons qui ne disposent que d'une émulation FM, il faut utiliser le programme sbiload. Ce programme est fourni avec les outils complémentaires d'ALSA, et disponible sur le site web du projet ALSA. Ce programme permet de charger dans le pilote les définitions des notes en modulation de fréquence. La syntaxe est la suivante :
Cette commande permet de charger dans le périphérique MIDI ALSA 65:0 les fichiers de définition de notes std.o3 et drums.o3. Ces fichiers sont fournis avec sbiload (pas dans toutes les versions toutefois). L'option--opl3
permet d'indiquer le format de ces fichiers. Quant à l'option -p, elle permet d'indiquer
le port MIDI dans le pilote ALSA. Les numéros de ports disponibles peuvent être obtenus avec la commande
suivante :
Note : La commande sbiload ne fonctionne qu'avec les ports MIDI FM.
Si le périphérique MIDI FM ne s'affiche pas, c'est que soit votre carte son n'en dispose pas, soit il n'a pas été activé dans le pilote et qu'il faut fournir l'option
fm_portau module ou au noyau lors de son démarrage, soit que le module snd-synth-opl3 n'a pas été chargé.
Pour les cartes son qui disposent d'une table d'échantillons, le programme à utiliser est différent. Pour les cartes Sound Blaster AWE et Sound Blaster Live, ce programme se nomme sfxload. Ce programme peut être trouvé sur le site http://mitglied.lycos.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 de prise en charge de votre carte son.Comme indiqué en introduction, la plupart des cartes son ne permettent pas de lire les fichiers MIDI au niveau matériel. 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 « échantillons » (« patches » en Anglais), 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 d'échantillons 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 ne disposant pas de la possibilité de lire les fichiers MIDI, il ne reste que la solution de l'émulation logicielle. Le meilleur synthétiseur logiciel sous Linux est incontestablement le logiciel Timidity. Timidity est un programme de lecture de fichiers MIDI très complet, paramétrable et capable d'utiliser des banques de sons 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. De plus, il est capable d'utiliser différentes interfaces pour lire et jouer les morceaux. En particulier, il peut être utilisé comme un serveur MIDI via ALSA afin que tous les programmes MIDI puissent y accéder via les interfaces standard d'ALSA. De même, il est capable de partager le canal audio de sortie de la carte son via le serveur de son aRts de KDE. Pour utiliser ces fonctionnalités, il faut configurer les sources avec la ligne de commande suivante :
./configure --prefix=/usr --enable-dynamic --enable-server \
--enable-interface=gtk,ncurse --enable-audio=arts,alsa,oss --enable-alsaseqUne 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/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. 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/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/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-ig à la ligne de commande
précédente. Enfin, si vous désirez utiliser Timidity en tant que séquenceur système ALSA et permettre
le mixage du flux audio qu'il produit avec les flux des autres applications par l'intermédiaire du
serveur de son aRts de l'environnement de développement de KDE, vous devrez utiliser
les options -iA -OR -B2,8 -EFreverb=0. Les programmes MIDI devront ensuite se connecter
sur le port MIDI 128:0 d'ALSA.
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 à deux niveaux 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 X.org 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 X.org.
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 modprobe.conf.
La suite des opérations se passe alors au niveau de la configuration du serveur X de X.org. L'activation du support de l'AGP et d'OpenGL se fait simplement en rajoutant deux options dans le fichier de configuration /etc/X11/xorg.conf. 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 X.org, 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 X.org.
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. Toutefois, 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.
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 les circuits intégrés Bt848 ou un de leurs 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 ne sont généralement pas 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/ soit par les distributions, soit par udev au démarrage du système, et vous n'aurez donc généralement 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 ». Si vous compilez cette fonctionnalité sous la forme de module, celui-ci sera nommé videodev. Ce pilote 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 ». Il est recommandé de compiler ces gestionnaires de périphériques sous la forme de modules, car il vous faudra sans doute spécifier des options afin d'adapter ces gestionnaires à votre matériel.
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 » (lui-même situé dans le menu « Character devices »).
De plus, le pilote prenant en charge les puces du type Bt848 ne prend pas en charge la gestion du son. Ces puces n'intègrent en effet pas de gestion du son, et nécessitent de brancher la sortie audio de la carte TV sur l'entrée ligne d'une carte son. Toutefois, un mixeur est disponible. Celui-ci est pris en charge automatiquement pour les pilotes de son ALSA. Pour les pilotes OSS en revanche, un gestionnaire spécifique devra être activé. L'option correspondante est l'option « TV card (bt848) mixer support ». Pour les puces Bt878, qui sont plus récentes, une carte son intégrée est fournie, et il existe un pilote complet ALSA et OSS, que l'on devra également activer.
Une fois le noyau recompilé et installé, il faut modifier les paramètres adaptés à votre matériel. En effet, 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. Cela est dû au fait que les 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, et bien souvent le modèle de tuner doit également être spécifié.
Si vous avez compilé les gestionnaires de périphériques
sous forme de module, vous pourrez spécifier le type de carte et le type de tuner simplement dans
le fichier de configuration /etc/modprobe.conf, à l'aide des options
du module du gestionnaire de périphérique adéquat. Pour les cartes basées sur la puce Bt848,
le gestionnaire de périphérique est pris en charge par le module bttv.
Le type de carte peut lui être communiqué à 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.bttv
du répertoire /usr/src/linux/Documentation/video4linux/bttv/.
Le type de tuner quant à lui doit être spécifié à l'aide de l'option tuner.
Cette option prend, elle aussi, une valeur numérique indiquant la nature du tuner utilisé.
Les valeurs supportées sont données dans le fichier CARDLIST.tuner.
En pratique, il est fort probable que vous utilisiez le type de tuner 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 modprobe.conf :
# Nom du module de gestion de Video For Linux : alias char-major-81 videodev # Nom du module à utiliser pour le premier périphérique vidéo : alias char-major-81-0 bttv # Options du module de gestion du Bt848 : options bttv card=1 tuner=3
Si vous ne désirez pas utiliser les modules du noyau, vous devrez fournir ces paramètres au gestionnaire de périphérique via la ligne de commande du noyau. Les options à utiliser peuvent alors être déduites des options du module, comme on l'a expliqué dans la Section 8.1.1.3. Pour notre exemple, ces paramètres seraient les suivants :
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 modprobe.conf :
# Nom du module de gestion des fonctionnalités I2C : alias char-major-89 i2c-dev # Activation de l'agorithme bit-banging : options i2c-algo-bit bit_test=1
Enfin, si vous utilisez les pilotes OSS pour la gestion du mixer de votre carte d'acquisition vidéo (ce qui est nécessaire pour les cartes vidéo basées sur les puces Bt848, parce qu'ALSA ne fournit pas de pilote pour ces cartes à l'heure actuelle), vous devrez définir les alias nécessaires au chargement des modules de cette carte lors de l'accès aux périphériques audio. Par exemple, pour une carte basée sur la puce Bt848, les alias suivants doivent être ajoutés dans le fichier de configuration modprobe.conf :
# Charge le pilote de la carte vidéo en tant que deuxième carte son : alias sound-slot-1 bttv # Charge le mixer de la carte son de cette carte : alias sound-service-1-0 tvmixer
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
typedu 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'optioncarddu 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 ou Xv 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 et Xv 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 « Networking 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 ». 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/modprobe.conf.
La compilation du noyau elle-même est 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.
Le Wifi (abréviation de l'anglais « Wireless Fidelity » est une technologie permettant de mettre plusieurs ordinateurs en réseau par ondes radio. La plage de fréquences utilisée est située dans la gamme des micro-ondes (2.44 GHz) et est soumise à une réglementation stricte dans de nombreux pays, car elle est en partie réservée aux applications militaires. En pratique, seuls certains canaux sont donc utilisables, et des dérogations peuvent être nécessaires pour une utilisation en extérieur. De plus, cette plage de fréquences est la même que celle utilisée par de nombreux autres appareils sans fil, comme les téléphones portables. Les communications sont donc fortement perturbables par ces appareils, ainsi bien sûr que par les fours à micro-ondes. Enfin, du fait même que ce sont des ondes radio, la confidentialité et la sécurité des communications peuvent être compromises.
Note : Comme pour toute onde proche des 2.4 GHz, l'influence des ondes radio Wifi sur les corps organiques humides n'est pas neutre (la problématique se pose bien entendu également pour les téléphones portables). En effet, les effets sont strictement les mêmes que ceux des ondes des fours à micro-ondes : ces ondes sont à la fréquence propre des molécules d'eau, qui entrent donc en résonnance en leur présence (cette interaction est due à la polarité de la molécule H2O, elle même due à son asymétrie - les atomes d'hydrogène et d'oxygène ne sont pas en ligne - et à la différence d'eléctronégativité entre les atomes d'hydrogène et d'oxygène qui la constituent). Les molécules d'eau restituent ensuite l'énergie de l'onde par diffusion de leur agitation moléculaire dans les molécules avoisinantes, ce qui provoque une augmentation de température. On est donc en droit de se poser la question du danger de l'utilisation de ces ondes pour l'organisme. En général, les puissances émises restent très faibles, et leur influence décroit de manière inversement proporionnelle au carré de la distance à l'émetteur, ce qui fait que le danger est relativement réduit. Toutefois, à titre personnel, et sans prétendre avoir fait la moindre étude sur le sujet, je vous invite à la prudence lors de l'utilisation d'ordinateurs ou de téléphones portables, en raison même de leur proximité (note : je n'ai pas de téléphone portable). Notez également que la chaleur directe dégagée par ces appareils par effet Joule est certainement la plus nocive, de même que leur utilisation prolongée pour l'équilibre mental...
Plusieurs normes de transmission ont été définies pour spécifier les interactions entre les appareils Wifi, ainsi que les technologies de chiffrement utilisées. La norme la plus répandue est la norme 802.11b, qui permet d'atteindre un débit de 11 Mbits/s théorique sur des distances allant jusqu'à 300 mètres en extérieur (quelques dizaines de mètres en intérieur). Toutefois, la plupart des adaptateurs Wifi implémentent également la norme 802.11g à présent. Cette norme permet en effet une compatibilité ascendante avec les équipements 802.11b d'une part (elle utilise la même plage de fréquences), et en constitue une amélioration conséquente puisque le débit théorique est relevé à 54 Mbits/s d'autre part (30 Mbits/s rééls). Notez qu'une autre norme concurrente du 802.11g a été définie, mais, n'étant pas compatible avec les équipements existants, elle n'a pas eu autant de succès. Il s'agit de la norme 802.11a, qui utilise une plage de fréquence à 5 GHz. Les problèmes d'interférences sont donc moindres, mais la portée est également réduite (plus la fréquence d'une onde radio est élevée, plus sa portée est réduite et plus elle est susceptible d'être bloquée par des objets).
Ces normes Wifi définissaient également un mécanisme de sécurité primitif, qui peut être considéré comme absolument inefficace de nos jours (il s'agit du WEP). En particulier, les algorithmes utilisés n'étaient pas fiables du tout et peuvent être cassés simplement par écoute du traffic pendant une période de temps relativement courte. De ce fait, de nouveaux mécanismes de sécurités ont été définis (notamment le WPA et le WPA2). Enfin, la norme 802.11i, encore peu répandue, a pour but d'améliorer la sécurité des communication en utilisant un véritable procédé cryptographique. Cette norme peut être transposée pour les appareils 802.11g et 802.11a.
Comme vous pouvez le constater, le terme Wifi cache bien des choses complexes, et le choix d'une technologie sur une autre peut être assez difficile.
Malgré tous ces inconvénients, la technologie Wifi est très pratique, car elle permet de connecter simplement des machines sans s'emmêler les pattes dans les câbles réseau. La plupart des ordinateurs portables vendus disposent maintenant d'un adaptateur réseau sans fil Wifi, et il est très facile d'en connecter un à un ordinateur de bureau, soit avec une carte fille, soit grâce à un adaptateur USB (il existe même des clefs USB dont l'encombrement est réduit à celui d'une gomme). Il est donc certain que ces technologies sont appelées à se développer et à se généraliser.
Certains matériels Wifi ne sont pas supportés nativement par Linux, soit parce que les constructeurs ne désirent pas fournir les informations permettant aux développeurs de faire un gestionnaire de périphérique libre, soit parce que les constructeurs n'ont eux-mêmes pas le droit de divulguer la technologie utilisée dans leurs appareils ou parce que les réglementation locales sur les émissions radio leur impose de tenir secret les caractéristiques de leurs appareils. Le choix d'un périphérique Wifi doit donc se faire avec précaution. Vous pourrez consulter le site Web de Jean Tourrilhes pour savoir le matériel supporté par les différents pilotes disponibles.
La prise en charge des périphériques Wifi nécessite d'activer le support du Wifi dans le noyau lui-même. Cela peut être fait en activant l'option « Wireless LAN drivers (non-hamradio) & Wireless Extensions » du menu « Network device support » du noyau. Cette option vous donnera également accès aux options de configuration des pilotes de périphériques Wifi (sauf pour certains périphériques USB, qui sont accessibles dans les options de configuration des périphériques USB). Certains pilotes ne sont pas encore intégrés au noyau, et vous devrez peut-être chercher sur Internet le pilote correspondant à votre matériel. Plusieurs projets ont en effet été créés afin de prendre en charge le Wifi sous Linux. Vous trouverez également sur le site de Jean Tourrilhes des liens vers les projets des pilotes pour les autres puces Wifi.
Si aucun pilote Linux n'est disponible pour votre matériel, vous pourrez vous rabattre sur le projet NDISWrapper (http://ndiswrapper.sourceforge.net). Ce projet a pour but de simuler la couche réseau NDIS de Windows XP afin de pouvoir charger les gestionnaires de périphériques pour Windows fournis par les fabricants, et les duper en leur faisant croire qu'ils s'exécutent bien sous Windows. Cette technique reste toutefois une magouille et ne résout bien entendu pas le problème de la disponibilité de pilotes libres.
L'installation des pilotes ne sera pas détaillée plus ici, car la manière de procéder est spécifique à chaque matériel. Dans le cas de NDISWrapper, l'installation se fait simplement en installant NDISWrapper lui-même et en exécutant la commande suivante :
où driver.inf est le fichier .inf du gestionnaire de périphérique pour Windows de votre matériel. Cette commande copie les fichiers nécessaires de ce gestionnaire de périphérique dans le répertoire /etc/ndiswrapper/ et définit la configuration pour l'utilisation de ce périphérique. Une fois cela fait, le chargement du module ndiswrapper suffit pour charger le gestionnaire de périphérique : Pour les autres gestionnaires de périphériques, il suffit généralement également de charger le module du noyau du pilote, et éventuellement de charger un firmware.Lorsque le pilote est chargé, une nouvelle interface réseau « wlanX » apparaît dans le système, où X est le numéro de l'interface réseau sans fil. Cette interface peut ensuite être utilisée comme n'importe quelle interface réseau, à ceci près qu'il faut au préalable configurer les paramètres du réseau sans fil. En particulier, il est nécessaire de spécifier le mode de fonctionnement, le canal à utiliser et l'identifiant du réseau sans fil. Une clef de chiffrement des communications peut également être donnée (cela ne garantit toutefois pas une sécurité absolue, sauf en 802.11i).
Les réseaux Wifi peuvent être établis de plusieurs manières. S'il s'agit de relier deux machines par Wifi, le mode de fonctionnement utilisé le plus simple est le mode « ad hoc ». Dans ce mode, les deux machines peuvent communiquer directement, sans avoir recours à une infrastructure quelconque. Inversement, si plusieurs machines doivent être reliées à un réseau existant (ou simplement entre elles), il est nécessaire d'installer ce qu'on appelle un « point d'accès », qui synchronisera les communications entre toutes ces machines. Dans ce cas, le mode de fonctionnement utilisé est le mode « managé ».
Le canal permet de spécifier la fréquence utilisée par les périphériques sans fil. Bien entendu, toutes les machines devant participer à la communication doivent utiliser le même canal. Le canal est donc un des paramètres essentiel du réseau. Il existe plusieurs canaux, mais en pratique, seuls quelques-uns peuvent être utilisés librement en France. Il s'agit des canaux 10 (2457 MHz), 11 (2462 MHz), 12 (2467 MHz) et 13 (2472 MHz).
Comme on peut être amené à créer plusieurs réseaux Wifi utilisant un même canal, il est nécessaire de pouvoir les distinguer afin d'éviter de mélanger les transmissions. Deux possibilités s'offrent alors à l'utilisateur : soit on utilise ce qu'on appelle un numéro de réseau virtuel (« Network ID »), soit on utilise un nom de réseau. La première solution ne permet de définir qu'une cellule du réseau, alors que la deuxième permet de regrouper plusieurs de ces cellules et autorise un utilisateur à passer d'une de ces cellules à l'autre (une cellule est une zone géographique prise en charge par un point d'accès).
Tous ces paramètres peuvent être spécifiés avec la commande iwconfig, sauf pour certains pilotes de périphériques non standards qui nécessitent des commandes spécifiques. La syntaxe générale de cette commande est la suivante :
iwconfig interface optionsoù interface est le nom de l'interface réseau sans fil (par exemple wlan0), et options est la liste des options permettant de définir les paramètres du réseau sans fil. Les principales options sont récapitulées dans le tableau suivant :
| Option | Signification |
|---|---|
| channel | Numéro du canal. |
| mode | Mode de fonctionnement. |
| essid | Nom de réseau. |
| nwid | Numéro de réseau. |
| key | Clef de chiffrement WEP du réseau. |
Les modes de fonctionnement les plus courants sont le mode « ad hoc » pour le mode ad hoc, et le mode « managed » pour l'utilisation d'un point d'accès. La page de manuel de iwconfig vous donnera la liste des autres modes utilisables.
Par exemple, pour configurer une interface sans fil sur le canal 11, en mode managé et avec un nom de réseau "MonWLAN", il faudra utiliser la commande suivante :
À la suite de cette commande, l'interface wlan0 sera utilisable comme n'importe quelle interface réseau.
Si vous désirez définir une clef de chiffrement pour votre réseau
sans fil, vous devrez utiliser l'option key. L'utilisation du chiffrement peut
être facultative en Wifi, sauf si l'interface est configurée pour n'accepter que les communications
chiffrées. L'option key peut donc accepter, en plus de la clef de chiffrement
(dont la taille est de 64 ou 104 bits, soit 8 ou 13 octets), un paramètre indiquant si le chiffrement
est obligatoire ou non. Ce paramètre peut prendre la valeur open si le chiffrement
est facultatif, restricted s'il est obligatoire, ou tout simplement
off si le chiffrement doit être désactivé.
Par exemple, pour imposer l'utilisation d'une clef de chiffrement sur l'interface wlan0, la commande suivante devra être utilisée :
Comme vous pouvez le constater, la clef est fournie en hexadécimal (c'est-à-dire en base 16, les chiffres au dessus de 9 étant représentés par les lettres A à F). Pour sortir du mode chiffré, la commande suivante pourra être utilisée :Sachez toutefois que le chiffrement WEP n'est pas fiable du tout, et qu'il ne faut pas se reposer dessus. Le chiffrement WPA, bien que n'étant pas encore supporté par tous les adaptateurs et tous les pilotes, est donc à privilégier. Outre l'utilisation d'algorithmes de chiffrement plus évolués, le chiffrement WPA permet de renégocier régulièrement les clefs de chiffrement utilisées par les interlocuteurs.
Sous Linux, cette négociation périodique est à la charge du démon wpa_supplicant. Ce démon prend en charge tous les aspects de la liaison Wifi, et rend par conséquent obsolète l'utilisation de la commande iwconfig pour la configuration du réseau sans fil. En effet, cette configuration doit se faire dans le fichier de configuration /etc/wpa_supplicant.conf, dont vous trouverez un exemple ci-dessous :
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="MonRezo"
key_mgmt=WPA-PSK
psk=1cc5a2db98bfd1387de265397772b9ea36e4d049e17fd1d660c014576d5e71a4
proto=WPA
}
L'option ctrl_interface permet de spécifier
un répertoire dans lequel wpa_supplicant placera des fichiers servant de
canaux de communication avec des programes complémentaires permettant de le contrôler et
d'obtenir des informations sur l'état de la liaison Wifi. La définition des paramètres
des réseaux sans fil se fait ensuite dans une section network, comme
vous pouvez le constater.
Le nom du réseau est obligatoire. Il doit être défini avec
l'option ssid. Le protocole de gestion de clef utilisé peut ensuite être spécifié
avec l'option key_mgmt. Dans cet exemple, il a été choisi d'utiliser une clef
secrète partagée (« PSK », abréviation de « Private Shared Key ») par toutes
les machines connectées au réseau sans fil. Cette configuration est très classique, et convient
en particulier pour tous les modems routeurs sans fil que l'on peut trouver dans le commerce.
La clef elle-même doit être spécifiée avec l'option
psk. Cette option peut prendre une chaîne de caractères ASCII entre
guillemets (exactement comme on a donné le nom du réseau à l'option ssid),
ou une valeur hexadécimale. La commande wpa_password permettra de créer
une telle valeur à partir d'une chaîne de caractère et du nom du réseau.
Enfin, l'option proto permet d'indiquer
le protocole de chiffrement utilisé. Dans le cas présent, nous avons utilisé le protocole
WPA, qui renégocie les clefs régulièrement. Le protocole
WPA2, intrinsèquement plus sûr, aurait pu être utilisé, mais n'a pas
été choisi parce que les points d'accès les plus anciens ne savent pas gérer ce protocole.
Note : Il est possible de définir plusieurs réseaux sans fil dans le fichier de configuration, dans ce cas, wpa_supplicant utilisera le premier réseau défini dans le fichier, en privilégiant les réseaux utilisant les protocoles de chiffrement les plus sûrs.
Cet exemple de fichier de configuration ne présente que le cas d'un réseau sans fil classique, dont les différentes machines partagent une même clef secrète de chiffrement. Sachez toutefois que wpa_supplicatn sait gérer des configurations plus complètes, dans lesquels des mécanismes de chiffrement plus évolués et des serveurs d'authentification peuvent être utilisés par exemple. Ces configurations ne seront pas abordées ici.
Une fois le fichier de configuration des réseaux sans fil mis en place, il ne reste plus qu'à lancer le démon wpa_supplicant. Typiquement, la commande à utiliser est la suivante :
Les optionsB et w permettent respectivement de faire
passer le processus ainsi lancé en arrière plan, et de lui demander d'attendre que
l'interface réseau à utiliser soit créée, si elle ne l'est pas encore lors de son lancement.
Le nom de cette interface est spécifié avec l'option i, et l'interface
de programmation à utilisée est spécifiée avec l'option D. Dans le cas
présent, l'interface de programmation utilisée est l'interface des extensions sans fil
classique de Linux (« wext », abréviation de « Wireless Extentions »).
Enfin, l'option c permet de spécifier le fichier de configuration à utiliser.
Il s'agit ici du fichier que l'on vient de décrire dans les paragraphes précédents.
Sachez enfin que la liste des réseaux sans fils disponibles
peut être récupérée avec l'option scan de la commande iwlist.
Par exemple, la commande suivante vous affichera tous les réseaux sans fils disponibles
via l'interface réseau wlan0, ainsi que leurs caractéristiques :
Pour finir, la commande iwconfig, utilisée sans option, affiche la configuration des interfaces sans fil du système. En particulier, vous y trouverez le mode de fonctionnement, le numéro de canal et les identifiants du réseau, éventuellement la clef de chiffrement utilisée, ainsi que la qualité du signal radio. La page de manuel de iwconfig vous donnera de plus amples informations sur la manière dont ces informations peuvent être interprétées.
| Précédent | Sommaire | Suivant |
| Configuration des périphériques de masse | Niveau supérieur | Configuration des ports de communication |