Guide d'installation et de configuration de Linux

Les modules peuvent être chargés manuellement à l'aide des commandes insmod et modprobe. modprobe est un peu plus évoluée, car elle gère les dépendances entre les modules et est capable de charger les modules utilisés par le module demandé. Leur utilisation est des plus simple :

insmod module

ou :

modprobe module

où module est le nom du module à charger.

En réalité, la commande modprobe appelle la commande insmod pour chaque module qui doit être chargé, dans l'ordre des dépendances des modules. De cette manière, chaque module peut être chargé sans problèmes, car toutes les fonctionnalités qu'il utilise sont déjà présentes dans le noyau lors de son chargement. La commande modprobe va chercher les informations de dépendances dans le fichier modules.dep, situé dans le répertoire /lib/module/version/. Ce fichier utilise une syntaxe très simple, et spécifie pour chaque module les modules dont il dépend. Bien qu'il puisse parfaitement être écrit à la main, cela nécessiterait d'avoir une connaissance approfondie des modules du noyau. C'est donc pour cela que l'outil depmod a été écrit. Cet outil permet de générer le fichier modules.dep automatiquement, pourvu qu'on l'appelle avec l'option -a en ligne de commande :

depmod -a

Il faudra donc appeler cette commande après chaque installation ou suppression de modules dans le système.

La liste de modules qui ont été chargés peut être obtenue aisément avec la commande lsmod :

lsmod

Enfin, la commande rmmod permet de décharger un module, avec la ligne de commande suivante :

rmmod module

On préférera cependant l'utilisation de la commande modprobe avec l'option -r pour décharger les modules, car cette commande est capable de décharger récursivement les modules dont dépendait le module à décharger lorsqu'ils ne sont eux-mêmes plus utilisés. La syntaxe est alors la suivante :

modprobe -r module

Note : En réalité, il n'est généralement pas nécessaire de charger les modules du noyau manuellement pour les pilotes de périphériques. En effet, comme nous allons le voir dans les sections suivantes, Linux dispose de mécanismes permettant de réaliser le chargement des modules de pilotes de périphériques automatiquement, lorsque ces pilotes sont détectés. Toutefois, il est possible que certains périphériques ne soient pas pris en charge par ces mécanismes (notamment les vieux périphériques ISA non Plug and Play).

La plupart des modules peuvent prendre un certain nombre d'options lors de leur chargement. Ces options permettent de fixer certains paramètres, et dans le cas des pilotes de périphériques, de préciser la configuration matérielle utilisée.

Les options des modules peuvent être spécifiées en ligne de commande lors de l'appel de insmod ou de modprobe. Toutefois, il est possible d'enregistrer ces options de manière permanente à l'aide du fichier de configuration /etc/modprobe.conf. Lors du chargement d'un module modprobe consulte en effet ce fichier et passe les paramètres indiqués au module à charger.

Afin de faciliter la maintenance du système, modprobe consulte également les fichiers de configuration situés dans le répertoire /etc/modprobe.d/. Ainsi, les options spécifiques à chaque module peuvent être placées dans un fichier de configuration dédié dans ce répertoire.

Le format de ces fichiers de configuration est assez simple, les options de chaque module se définissant sur une ligne commençant par le mot clé options. Ce mot clé doit être suivi du nom du module pour lequel ces options sont définies, lui-même suivi des paramètres de chargement du module. La syntaxe est donc la suivante :

options module paramètres

La liste des paramètres que l'on peut passer à un module dépend bien évidemment du module. Vous pouvez obtenir la liste des options supportées par un module à l'aide de l'option -p de la commande modinfo :

modinfo -p module

Nous verrons par la suite des exemples de passage de paramètres pour les modules les plus courants.

Les fichiers de configuration de modprobe permettent également de définir la manière dont le chargement et le déchargement des modules doivent être faits. Pour cela, il permet de spécifier une ligne de commande complète pour ces opérations. Ces lignes de commandes sont introduites via les mots-clefs install et remove. La syntaxe de ces mots-clés est la suivante :

install module commande
remove module commande

où module est le nom du module à charger ou à décharger, et commande est la ligne de commande de l'opération à effectuer pour cela.

Par exemple, si le port parallèle est utilisé pour accéder à un périphérique nécessitant une opération d'initialisation quelconque, celle-ci peut être exécutée lors du chargement du module à l'aide du mot clé install :

install parport_pc modprobe parport_pc --ignore-install && initperiph

(en supposant que la commande initperiph permet d'initialiser le périphérique en question). Évidemment, ce type d'opération dépend du matériel connecté sur le port parallèle, mais le principe est là. Vous noterez que pour éviter que la commande modprobe ne boucle sur elle-même dans la commande indiquée par la directive install, l'option --ignore-install lui a été fournie. Dans le cas d'une directive remove, il faudrait utiliser l'option --ignore-remove.

Dans la plupart des cas, la définition de ces commandes de chargement et de déchargement est facultative, car les modules utilisent généralement un jeu de paramètres implicites qui permettent de les utiliser même si le fichier de configuration modprobe.conf est absent. Vous pouvez visualiser ces options en renommant le fichier de configuration modprobe.conf et en tapant la commande suivante :

modprobe -c

Cette commande vous permettra également de recréer un nouveau fichier de configuration si d'aventure vous perdiez celui fourni avec votre distribution.

La plupart des fonctionnalités disponibles sous la forme de modules peuvent également être intégrées directement dans le noyau, lors de la compilation de celui-ci. Il est évident qu'il n'est alors pas possible d'utiliser les fichiers de configuration de modprobe pour fixer les valeurs des différentes options que ces fonctionnalités peuvent utiliser. En effet, ces paramètres doivent dans ce cas être définis dès le démarrage du système, et il est nécessaire de les fournir dès le chargement du noyau en mémoire.

Cela se fait, comme nous l'avons vu dans la Section 3.4.7, en fournissant au noyau les paramètres en question sur sa ligne de commande. Nous avons déjà vu comment la quantité de mémoire de l'ordinateur pouvait être passée au noyau à l'aide de l'option mem si elle n'était pas détectée correctement. Il est possible de spécifier de la même manière de nombreuses autres options, en particulier pour activer ou désactiver certains gestionnaires de périphériques ou pour leur indiquer les paramètres du matériel.

Les options fournies au noyau sur sa ligne de commande par le gestionnaire d'amorçage sont lues par le noyau dès son démarrage, afin de fixer les paramètres qu'elles décrivent jusqu'au redémarrage suivant. Pour certaines fonctionnalités, ces paramètres peuvent toutefois être modifiées dynamiquement après le démarrage, via le système de fichiers virtuel /proc/.

Il existe un grand nombre d'options, et leur syntaxe varie en fonction du sous-système qui les utilise. Le fichier de documentation kernel-parameters.txt du répertoire Documentation/ des sources du noyau vous donnera la liste complète de ces options. Nous verrons quelques-unes de ces options spécifiquement dans la suite du chapitre, lorsque nous décrirons les paramètres des gestionnaires de périphériques.

En revanche, les options des modules intégrés au noyau suivent toujours la même syntaxe. Cette syntaxe est la suivante :

module.paramètre=valeur

où module est le nom du module du noyau qui implémente la fonctionnalité lorsqu'elle est utilisée sous la forme de module, paramètre est le nom de l'option de ce module du noyau telle qu'elle est donnée par la commande modinfo, et valeur est sa valeur. Ainsi, si vous voulez intégrer une fonctionnalité d'un module dans le noyau, il suffit simplement d'ajouter les paramètres complémentaires dans la ligne de commande de celui-ci en fonction des options définies dans les fichiers de configuration de modprobe. Nous verrons la manière de procéder plus loin dans ce chapitre.

Note : Intégrer un pilote de périphérique directement dans le noyau peut être intéressant si ce périphérique est inamovible et que l'on ne veut pas avoir à prendre en charge les modules. Toutefois, ce n'est pas une bonne idée lorsqu'on installe ce périphérique et qu'on cherche à le configurer, ou si l'on désire se réserver la possibilité de faire une mise à jour de ce périphérique sans redémarrer l'ordinateur. En effet, il est souvent nécessaire de redémarrer pour prendre en compte de nouveaux paramètres lorsque le pilote de périphérique est intégré au noyau, alors que lorsqu'il est sous la forme d'un module, un simple déchargement et rechargement suffit.

Par contre, lorsque votre configuration sera finie, vous pourrez parfaitement vous passer des modules et supprimer les modules des pilotes de périphériques dont vous ne disposez pas. Vous gagnerez ainsi de la place disque et potentiellement plusieurs dizaines de secondes au démarrage de votre ordinateur si votre distribution recherche les nouveaux périphériques à chaque démarrage.

La notion de fichier spécial de périphérique simplifie énormément l'utilisation du matériel par les programmes d'application, puisque la plupart des opérations sur un périphérique reviennent simplement à réaliser une écriture ou une lecture. Évidemment, l'écriture sur un fichier spécial de disque permet d'enregistrer les données sur ce disque, et la lecture permet de les récupérer. Mais cela ne s'arrête pas là ! Par exemple, la communication avec le modem se fait simplement en écrivant et en lisant les données sur le fichier spécial du port série sur lequel le modem est connecté. De même, jouer un fichier son revient simplement à l'écrire dans le fichier spécial qui gère la carte son. Il est même possible d'accéder à la mémoire vidéo par l'intermédiaire d'un fichier spécial de périphérique…

Bien entendu, certaines fonctionnalités avancées des périphériques ne peuvent pas être accédées simplement par une écriture ou une lecture dans un fichier spécial. Le système fournit donc aux applications d'autres moyens d'accéder à ces fonctionnalités, par l'intermédiaire d'appels systèmes spécifiques (pour ceux qui sont intéressés par la programmation système, cet appel système est réalisé par la fonction ioctl, dont le nom provient de l'abréviation de l'anglais « Input / Output ConTroL »). Évidemment, cette méthode n'est utilisée que par les programmes qui connaissent bien le fonctionnement du gestionnaire du périphérique, car ils doivent spécifier une requête que seul ce gestionnaire comprend en général. Quoi qu'il en soit, les requêtes de ce type utilisent elles aussi un descripteur de fichier spécial de périphérique, ce qui fait que tous les accès au matériel ont lieu par l'intermédiaire de ces fichiers.

Il existe deux principaux types de fichiers spéciaux de périphériques. Le premier type correspond aux périphériques de type bloc, dont les données ne peuvent être lues que par blocs (c'est le cas des disques durs, des lecteurs de CD et de disquettes en particulier). Le deuxième type correspond aux périphériques de type caractère, dont les données peuvent être lues caractère par caractère (cartes son, ports série, etc.).

En plus de son type, chaque fichier spécial de périphérique est caractérisé par deux codes permettant d'identifier le type et le modèle du périphérique auquel il donne accès. Ces deux codes portent le nom de code majeur et de code mineur. C'est par l'intermédiaire de ces codes que le noyau est capable de retrouver le gestionnaire de périphériques à utiliser pour satisfaire aux requêtes des clients qui accèdent à un fichier spécial de périphérique. Il y a donc, en général, une association unique entre ces codes et les gestionnaires de périphériques.

Les fichiers spéciaux de périphériques sont tous stockés dans le répertoire /dev/. Selon votre distribution, ce répertoire peut être géré de manière totalement dynamique en fonction du matériel effectivement installé sur votre machine, ou être prérempli statiquement avec les fichiers spéciaux de la plupart des périphériques rencontrés sur le marché (y compris donc pour des périphériques inexistants sur votre machine). Nous allons voir dans les sections suivantes comment ces fichiers sont créés et utilisés par le système en relation avec les pilotes de périphériques.

VIII-A-2-b-i. Présentation▲

VIII-A-2-b-ii. Principe de fonctionnements de udev▲

KERNEL=="mem", NAME="%k", GROUP="kmem", MODE="0640"
KERNEL=="kmem", NAME="%k", GROUP="kmem", MODE="0640"

VIII-A-2-b-iii. Identification et chargement des pilotes de périphérique▲

Généralement, les périphériques modernes disposent d'identifiants qui leur sont propres et qui peuvent être récupérés par des mécanismes standards des bus modernes. Ces identifiants sont généralement au nombre de deux, le premier étant un code spécifique au fabricant du périphérique, et le deuxième étant un identifiant de ce périphérique. Par exemple, vous pouvez visualiser les différents périphériques connectés au bus PCI de votre ordinateur avec la simple commande lspci -nn. La commande lsusb vous donnera des identifiants similaires pour les périphériques USB.

udev peut déterminer, à l'aide des identifiants du matériel, déterminer quels sont les pilotes de périphériques capables de gérer ce matériel. En effet, les fichiers sources de chaque module de pilote de périphérique contiennent une liste des identifiants des périphériques qu'ils prennent en charge. Lors de l'installation du module, la commande depmod extrait ces informations et les place dans un des fichiers situés dans le répertoire d'installation des modules du noyau (à savoir /lib/module/version/, où version est le numéro de version du noyau). depmod crée un fichier pour chaque type de périphérique. Ces fichiers ont tous un nom de la forme :

 

Sélectionnez

module.typemap

où type est le type de périphérique.

Par exemple, le fichier module.usbmap contient, pour chaque périphérique USB pris en charge par les modules installés, une ligne indiquant le nom du module et l'ensemble des identifiants du périphérique USB en question.

Ainsi, lorsque le noyau indique à udev l'apparition d'un nouveau périphérique, celui-ci consulte les fichiers d'association des modules aux périphériques pour déterminer quel module est capable de gérer ce périphérique. Ce module est chargé si nécessaire, et le gestionnaire de périphérique peut s'initialiser.

Note : La table des périphériques pris en charge par certains modules peut ne pas être complète ou à jour. C'est généralement le cas pour les nouveaux périphériques vendus par un fabricant qui utilisent une nouvelle révision d'une puce électronique que des anciens périphériques supportés par un pilote utilisaient déjà. Ainsi, lorsqu'un périphérique n'est pas reconnu immédiatement par les pilotes existants, vous pouvez tenter une recherche sur Internet avec les identifiants de périphériques tels qu'ils sont donnés par lspci ou lsusb et identifier le pilote nécessaire pour ce périphérique. S'il en existe un, vous pouvez essayer d'ajouter les identifiants de votre périphérique dans les sources du pilote, le recompiler et l'installer à nouveau. Si ce pilote vous permet d'utiliser effectivement ce périphérique de manière stable, vous pouvez alors demander au mainteneur du pilote d'ajouter les identifiants du périphérique dans la liste des périphériques supportés.

VIII-A-2-b-iv. Chargement des firmwares▲

Certains périphériques nécessitent un firmware (c'est-à-dire un micro logiciel pour les périphériques évolués) pour fonctionner correctement. Ce firmware peut être stocké de manière permanente dans le périphérique dans une mémoire non volatile, ou devoir être rechargé à chaque initialisation du périphérique. Dans ce cas, cette opération de chargement doit être faite par le pilote de périphérique.

Grâce à udev, il est possible de faire en sorte que cette opération se fasse automatiquement. Lorsqu'un pilote désire charger le firmware dans le périphérique, il appelle une fonction du noyau qui génère un événement udev. udev prend alors en charge les opérations et localise le firmware, puis le fournit au noyau. Le pilote de périphérique peut alors effectuer le chargement effectif du firmware dans le périphérique. Pour cela, udev copie le fichier de firmware demandé par le pilote de périphérique dans un fichier dédié à cet effet dans l'entrée du périphérique du système de fichiers virtuel /sys/. Bien entendu, le chemin permettant de trouver les informations du périphérique dans le système de fichiers virtuel /sys/ est fourni aux scripts de configuration d'udev via le mot clé DEVPATH.

En général, les fichiers de firmware sont fournis avec les pilotes de périphériques ou sont disponibles sur le site Web indiqué dans leur documentation. Ils doivent être installés dans le répertoire /lib/firmware/. Il est également nécessaire d''activer l'option « Hotplug firmware loading support » du sous-menu « Generic Driver Options » du menu « Device Drivers » pour que cette fonctionnalité soit disponible.

VIII-A-2-b-v. Création des fichiers spéciaux de périphériques▲

À chaque périphérique détecté par un pilote de périphérique, le noyau génère un événement à destination d'udev. Ces événements indiquent le nom du périphérique tel qu'il est connu par le gestionnaire de périphérique, ainsi que les informations sur le périphérique dans le système de fichiers /sys/. udev utilise ces informations pour déterminer les règles qui indiquent quels sont les fichiers spéciaux de périphériques à utiliser.

Si aucune règle ne correspond, udev crée le fichier spécial de périphérique avec le nom utilisé par le pilote de périphérique pour l'identifier. Dans le cas contraire, c'est le nom fourni dans les fichiers de configuration qui est utilisé. De même, les fichiers sont créés par défaut au nom de l'utilisateur root, et seul cet utilisateur dispose des droits de lecture et d'écriture sur ces fichiers. Enfin, si des liens symboliques sont définis dans les règles appliquées, ceux-ci sont créés. Par exemple, il est classique d'avoir un lien symbolique cd-rom pointant vers le périphérique de type bloc gérant le lecteur de CD.

Les règles d'udev sont généralement fournies par les distributions et permettent de créer les fichiers spéciaux de périphériques de manière générique, ainsi que les liens symboliques standards. De même, bien que les interfaces réseau ne sont pas accédées par l'intermédiaire de fichiers spéciaux de périphériques, les règles udev sont également appliquées afin de les renommer sous un nom spécifique.

VIII-A-2-b-vi. Persistance des fichiers spéciaux de périphériques▲

udevinfo --name=/dev/sdb --attribute-walk

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/block/sdb':
    KERNEL=="sdb"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{capability}=="12"
    ATTR{stat}=="      52      127      556      486        0        0        0        0        0      426      486"
    ATTR{size}=="156301488"
    ATTR{removable}=="0"
    ATTR{range}=="16"
    ATTR{dev}=="8:16"

  looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-2/1-2:1.0/host5/target5:0:0/5:0:0:0':
    KERNELS=="5:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{modalias}=="scsi:t-0x00"
    ATTRS{ioerr_cnt}=="0x0"
    ATTRS{iodone_cnt}=="0x3b"
    ATTRS{iorequest_cnt}=="0x3b"
    ATTRS{iocounterbits}=="32"
    ATTRS{timeout}=="30"
    ATTRS{state}=="running"
    ATTRS{rev}=="09.0"
    ATTRS{model}=="WD800VE-00HDT0  "
    ATTRS{vendor}=="WDC     "
    ATTRS{scsi_level}=="3"
    ATTRS{type}=="0"
    ATTRS{queue_type}=="none"
    ATTRS{queue_depth}=="1"
    ATTRS{device_blocked}=="0"
    ATTRS{max_sectors}=="240"

…

SUBSYSTEMS=="scsi", ATTRS{model}=="WD800VE-00HDT0", NAME="hd_externe"

udevtest /sys/block/sdb

VIII-A-2-b-vii. Notification des applications utilisateurs▲

VIII-A-2-b-viii. Initialisation du système▲

La gestion des périphériques et du répertoire /dev/ par udev est utilisée par la plupart des distributions récentes. Toutefois, les anciennes distributions sont encore susceptibles d'utiliser un répertoire /dev/ complètement statique, c'est-à-dire rempli à l'avance avec les fichiers spéciaux des périphériques les plus courants.

Normalement, votre distribution fournit un répertoire /dev/ relativement complet. Vous n'avez donc pas à toucher au répertoire /dev/. Cependant, si vous devez créer un fichier spécial de périphérique vous-même, par exemple pour un gestionnaire de périphérique exotique non pris en charge par votre distribution ou non reconnu par le système, vous devrez utiliser la commande mknod. Sa syntaxe est relativement simple :

mknod fichier type majeur mineur

où fichier est le nom du fichier spécial de périphérique à créer, type est une lettre indiquant le type du fichier spécial ('c' pour les fichiers de type caractère et 'b' pour les fichiers de type bloc), et majeur et mineur sont les codes majeur et mineur du périphérique. Je vous invite à consulter la page de manuel de la commande mknod pour plus d'informations.

Note : La liste des codes majeurs et mineurs déjà affectés à des périphériques est donnée dans le fichier /usr/src/linux/Documentation/devices.txt. Comme vous pouvez le constater, l'utilisation d'un répertoire /dev/ statique impose donc de disposer d'une autorité centrale régissant l'affectation des codes majeurs et mineurs aux gestionnaires de périphériques. De plus, la plupart des codes sont déjà affectés, ce qui est une des raisons pour laquelle le système udev a été développé.

Lorsqu'une application tente d'accéder à un fichier spécial de périphérique, trois cas peuvent se présenter :

• soit un pilote de périphérique capable de gérer le périphérique est déjà chargé ;
• soit il n'existe aucun pilote capable de gérer le périphérique, mais le noyau peut en trouver un ;
• soit le noyau est incapable de trouver un pilote pour ce périphérique.

Dans les deux premiers cas, la requête de l'application est satisfaite, éventuellement après le chargement automatique du pilote de périphérique sous la forme de module. Dans le troisième cas, évidemment, la requête est refusée.

Ainsi, lors de l'ouverture d'un fichier spécial de périphérique par une application, le noyau vérifie s'il dispose d'un pilote de périphérique capable de gérer ce périphérique, en s'appuyant sur les codes majeur et mineur du fichier spécial de périphérique. Si ce n'est pas le cas, il effectue un appel à modprobe pour charger le module contenant ce pilote de périphérique.

Le nom du module dont le noyau demande le chargement à modprobe dépend du pilote et ne correspond pas forcément à un nom de module existant. Par exemple, le module de gestion des ports parallèles se nomme, sur les ordinateurs de type PC, parport_pc. Toutefois, lorsque le noyau désire accéder au port parallèle, il n'utilise pas ce nom, mais plutôt un nom générique, qui est le même pour toutes les architectures matérielles supportées par Linux. Ce nom est parport_lowlevel. Ainsi, le noyau utilise la commande suivante pour charger le module de prise en charge du port parallèle :

modprobe -k parport_lowlevel

L'option -k permet d'indiquer à modprobe qu'il est appelé par le noyau, donc dans le contexte de chargement automatique des modules.

modprobe doit donc faire la correspondance entre le nom de module demandé par le noyau et le nom d'un module réel. C'est donc dans les fichiers de configuration de modprobe que cette correspondance est définie. Pour cela, un certain nombre d'alias peuvent être définis pour identifier les modules réels. Chaque alias est introduit par le mot clé alias, dont la syntaxe est donnée ci-dessous :

alias nom module

où nom est le nom de l'alias, et module est le nom du module réel. Lorsque la commande modprobe est appelée avec le nom d'un alias en paramètre, elle commence par rechercher le nom du module réel dans ses fichiers de configuration, puis elle le charge en mémoire.

Par exemple, pour charger le module parport_pc automatiquement lorsque le noyau a besoin d'accéder au port parallèle, on pourra ajouter la définition d'alias suivante dans le fichier modprobe.conf :

alias parport_lowlevel parport_pc

Vous pouvez constater que le mécanisme d'alias permet de rendre le noyau indépendant des modules utilisés, puisque l'association entre le nom du module utilisé par le noyau et le module réel et ses paramètres est maintenue dans des fichiers de configuration. L'inconvénient de cette méthode est en revanche qu'il faut connaître les noms de modules utilisés par le noyau pour chaque pilote et pour leurs fonctionnalités. Ces noms sont assez variables et dépendent de la fonctionnalité demandée. En général, ce nom apparaît dans les messages de traces du noyau lorsqu'il ne parvient pas à localiser un module lors de son chargement automatique. Ces messages de traces peuvent être affichés à l'aide de la commande dmesg. Il est donc possible de déterminer la liste des modules que le noyau a tenté de charger relativement facilement. Toutefois, cela n'indique pas forcément la fonctionnalité implémentée par le module en question, et encore moins l'application qui a tenté d'utiliser cette fonctionnalité.

Il est heureusement beaucoup plus facile de savoir quelle est la fonctionnalité demandée lorsque celle-ci a trait à un périphérique de l'ordinateur. En effet, le nom de module utilisé par le noyau pour chaque gestionnaire de périphérique est construit à partir du type de fichier spécial de périphérique et de ses codes majeur et mineur. Ainsi, le noyau utilise un nom de module de la forme « char-major-xxxx » pour les périphériques de type caractère, et un nom de la forme « block-major-xxxx » pour les périphériques de type bloc. Les caractères xxxx identifient le code majeur de ce périphérique, plus rarement son code mineur. Il est donc facile de déduire le gestionnaire de périphérique nécessaire à la gestion de ce fichier spécial de périphérique, et de définir l'alias permettant de faire la correspondance entre le nom du module utilisé par le noyau et le module réel à charger.

Par exemple, pour les cartes son, le nom de module char-major-14 est utilisé pour demander le chargement du module de gestion du son, parce que les cartes son utilisent toutes le code majeur 14. Il faut donc définir un alias sur ce nom de module vers le module du gestionnaire de cartes son. Comme on le verra dans la section traitant de la configuration des cartes son, ce module pourra lui-même demander le chargement de modules complémentaires, en fonction de la carte son réellement utilisée et des fonctionnalités demandées. Le numéro de code mineur sera indiqué lors de ces opérations.

Si vous devez modifier les fichiers de configuration de modprobe, sachez qu'il s'agit d'une opération délicate, car elle nécessite de bien connaître les mécanismes de nommage utilisés par le noyau, les noms des modules réels et leurs paramètres de configuration. En général, vous trouverez les informations sur les entrées à ajouter ou à modifier dans le fichier d'aide du module correspondant, que vous pourrez trouver dans les sources du noyau (dans le répertoire /usr/src/linux/Documentation/). Quoi qu'il en soit, la modification des fichiers de configuration de modprobe peut générer de nouvelles dépendances entre les modules. Il est donc nécessaire d'exécuter la commande depmod -a après chaque modification de ce fichier.

Originellement, tous les graveurs de CD/DVD utilisaient l'interface SCSI. Ce n'est que plus tard que les graveurs sur port parallèle et les graveurs IDE ATAPI sont apparus. Actuellement, les graveurs externes connectés sur port parallèle sont de moins en moins vendus. Les graveurs IDE on fait une belle percée et sont les plus courants actuellement. Les logiciels de gravage doivent donc toutefois être capables d'utiliser n'importe quel type de graveur, ce qui n'est pas simple. Heureusement, le protocole de communication ATAPI n'est rien d'autre qu'un mode de transport de commandes SCSI pour les périphériques IDE, ce qui fait que les logiciels de gravage peuvent utiliser les deux types de périphériques de manière relativement générique.

Les anciennes versions des logiciels de gravage ne permettaient d'utiliser que l'interface SCSI pour graver des CD. Il n'était donc pas possible d'utiliser les graveurs IDE de manière native. Une couche d'émulation SCSI a donc été développée dans Linux afin de simuler une interface SCSI pour les périphériques IDE, et de traduire à la volée les commandes SCSI en commandes ATAPI. À présent, les logiciels de gravage sont tous capables d'utiliser nativement les graveurs IDE, et cette couche d'émulation n'est plus que très rarement nécessaire. Elle ne sera donc pas décrite plus en détail ici.

L'utilisation des graveurs de CD/DVD ne requiert généralement pas d'option particulière au niveau de la configuration. Autrement dit, si vous pouvez utiliser votre graveur comme un simple lecteur, alors vous pouvez également l'utiliser pour graver. Cependant, il peut-être intéressant d'activer le support de certains systèmes de fichiers pour utiliser correctement les lecteurs et les graveurs.

Les principales options de configuration du noyau ayant trait aux lecteurs et aux graveurs de CD/DVD sont récapitulées ci-dessous :

« Loopback device support »

Cette option permet d'activer une fonctionnalité permettant d'utiliser un fichier comme un périphérique normal. Elle est très utile pour tester les images de CD, car il suffit simplement de monter le fichier image comme un périphérique « loopback ». Il est donc recommandé d'activer cette fonctionnalité, que l'on dispose d'un graveur SCSI ou IDE. Cette fonctionnalité peut être activée sous la forme de module ou non, la réponse recommandée est 'Y'.

« Include IDE/ATA-2 CDROM support »

Cette option permet d'activer la gestion des lecteurs de CD IDE ATAPI. Vous devez répondre à cette question par 'Y' si vous disposez d'un graveur ou d'un lecteur IDE, ce qui est généralement le cas. La réponse recommandée est 'Y'.

« SCSI support »

Cette option permet d'activer la gestion des périphériques SCSI dans votre noyau. Il va de soi qu'il faut l'activer si vous disposez d'un graveur SCSI. Cette fonctionnalité peut être activée sous forme de module ou non. La réponse recommandée est 'N'.

« SCSI CD-ROM support »

Cette option permet d'activer la gestion des lecteurs de CD SCSI. Il faut l'activer si l'on dispose d'un graveur SCSI. La réponse recommandée est 'Y' si vous disposez d'un lecteur ou d'un graveur SCSI, et 'N' dans le cas contraire.

« Enable vendor-specific extensions (for SCSI CDROM) »

Cette option permet d'autoriser l'emploi d'extensions au protocole SCSI définies par les fabricants de matériels. Certains graveurs utilisent de telles extensions, c'est en particulier le cas des graveurs de CD HP. Toutefois, si vous ne disposez pas d'un tel graveur, il est peu probable que vous ayez à activer cette fonctionnalité. La réponse recommandée est donc 'N'.

« SCSI generic support »

Cette option permet d'utiliser les périphériques SCSI avec des commandes non standards, ce qui requiert l'emploi de programmes capables de communiquer directement avec les périphériques SCSI. C'est le cas pour les graveurs, qui seront pilotés directement par les logiciels de gravage. Il faut généralement activer cette fonctionnalité si l'on dispose de périphérique SCSI, aussi la réponse recommandée est-elle 'Y' si l'on se trouve dans cette situation.

« Probe all LUNs on each SCSI device »

Cette option permet, lorsqu'on dispose de périphériques SCSI capables de gérer plusieurs numéros d'unité logiques, de leur demander tous ces numéros. Ce type de périphérique est assez rare, et en général chaque périphérique n'utilise qu'un et un seul numéro d'unité logique. Il ne faut donc pas, en général, activer cette fonctionnalité. La réponse recommandée pour cette question est donc 'N'.

« ISO 9660 CDROM file system support »

Cette option permet de prendre en charge les systèmes de fichiers des CD-ROM. Il est impératif d'activer cette fonctionnalité, aussi la réponse recommandée pour cette question est-elle 'Y'.

« Microsoft Joliet CDROM extensions »

Cette option permet de prendre en charge les extensions Microsoft au système de fichiers ISO 9660 (pour la gestion des noms longs du DOS). Étant donné le nombre de CD qui utilisent ces extensions, il est impératif d'activer cette fonctionnalité. La réponse recommandée pour cette question est donc 'Y'.

« UDF file system support »

Cette option permet de prendre en charge les systèmes de fichiers UDF, utilisé par certains CD-ROM gravés par paquets et par tous les DVD. Il est impératif d'activer cette fonctionnalité, aussi la réponse recommandée pour cette question est-elle 'Y'.

Enfin, il faut choisir le pilote bas niveau permettant de gérer son graveur de CD. Pour les graveurs IDE ATAPI il n'y a pas de pilote bas niveau à inclure. Pour les graveurs SCSI, il faut choisir le pilote approprié de votre carte ou de votre contrôleur SCSI.

Une fois cette configuration effectuée, il ne reste plus qu'à compiler le noyau et les modules et à les installer. La manière de procéder a été décrite dans la section traitant de la compilation du noyau.

Vous aurez sans doute à modifier le fichier de configuration /etc/modprobe.conf si vous avez activé certaines fonctionnalités SCSI sous la forme de modules, afin de charger les modules nécessaires lorsqu'une commande sera effectuée sur l'un des fichiers spéciaux de périphériques SCSI. Si toutes les fonctionnalités SCSI sont intégrées au noyau, cette étape est bien entendu facultative. Les fichiers spéciaux utiles pour les périphériques blocs SCSI sont les fichiers scdx et sgx, où x est le numéro du périphérique. Les fichiers spéciaux du premier groupe sont de type bloc, et permettent d'accéder aux lecteurs de CD SCSI. Les fichiers du deuxième groupe en revanche sont de type caractère, et permettent d'accéder aux périphériques SCSI de manière générique. Les codes majeurs pour ces deux groupes de fichiers spéciaux sont respectivement 11 et 21, il faut donc ajouter les entrées du fichier modprobe.conf pour les modules nommés block-major-11 et char-major-21. Normalement, ces entrées sont déjà présentes dans le fichier fourni par votre distribution.

Lorsque le noyau aura été correctement configuré et installé, il ne vous restera plus qu'à installer les logiciels de gravage. Les logiciels indispensables sont les suivants :

• cdrecord, qui permet de piloter le graveur de CD et d'effectuer les tâches nécessaires pour le gravage ;
• mkisofs, qui permet de créer des images disques ISO 9660, éventuellement avec les extensions Joliet (CD Windows 95), Rock Ridge (CD Unix) ou HFS (CD Macintosh) ;
• cdda2wav, qui permet d'extraire les données numériques des CD audio ;
• cdrdao, qui permet de réaliser des gravages bas niveau et en mode « Disk At Once ».

Vous pourrez vérifier que votre configuration fonctionne correctement si vous disposez d'un périphérique SCSI ou si vous utilisez l'émulation SCSI avec la commande suivante :

cdrecord -scanbus

Cette commande recherche tous les périphériques SCSI du système. Vous devrez normalement y trouver, en plus de vos autres périphériques SCSI, votre graveur de CD. Cette commande ne fonctionne pas si vous utilisez un graveur IDE.

Nous allons à présent voir les commandes permettant de faire les principales opérations ayant trait au gravage des CD. Bien que ce document soit consacré à l'installation de Linux et non à son utilisation, elles vous permettront de tester si tout fonctionne correctement.

La copie directe d'un CD peut se faire avec la commande suivante :

cdrecord -dummy -v dev=graveur speed=n -isosize /dev/source

L'option dev permet de spécifier le périphérique du graveur à utiliser. Cette option peut prendre en paramètre soit le fichier spécial de périphérique du graveur (par exemple /dev/hdc), soit un triplet de valeur permettant d'identifier un périphérique sur le bus SCSI (par exemple 0,1,0). La première valeur représente le bus SCSI sur lequel le graveur est branché, la deuxième le numéro de périphérique du graveur sur ce bus SCSI et la troisième son numéro d'unité logique (« Logical Unit Number »). Le numéro du bus SCSI et le numéro de périphérique peuvent être obtenus avec la commande cdrecord -scanbus présentée ci-dessus si vous utilisez un graveur SCSI. Le numéro d'unité logique est, dans la majorité des cas, 0.

Le nombre n donné dans la ligne de commande précédente doit valoir le facteur multiplicateur de la vitesse de gravage. Vous pouvez essayer avec des valeurs faibles pour commencer, afin d'être sûr que tout se passe bien. Le fichier de périphérique /dev/source quant à lui représente le fichier spécial de périphérique du lecteur de CD utilisé pour lire le CD-ROM. L'option -isosize permet de demander à cdrecord de lire la taille de la piste à graver dans le système de fichiers ISO9660 du CD source. Enfin, l'option -dummy permet de faire toutes les opérations en conservant le laser du graveur éteint, ce qui revient à faire un test. Si vous voulez réellement graver votre CD, il suffit de supprimer cette option.

Il va de soi que si vous ne disposez pas d'un lecteur de CD en plus de votre graveur, vous ne pouvez pas utiliser la commande précédente. Dans ce cas, vous devrez faire une image disque en extrayant toutes les données du CD source. Cela peut être réalisé avec la commande suivante :

dd if=/dev/source of=image

où /dev/source est le fichier spécial de périphérique du lecteur utilisé pour faire l'image, et image est le fichier image qui doit être créé.

Le gravage d'une image disque peut être réalisé avec la commande suivante :

cdrecord -dummy -v dev=graveur speed=n -data image

où les options sont les mêmes que dans les commandes précédentes.

Si vous désirez créer une image disque à partir des fichiers de votre disque dur, vous pouvez utiliser mkisofs. Ce programme permet de créer une image disque ISO9660, avec les extensions Rock Ridge pour activer les fonctionnalités des systèmes de fichiers Unix (noms de fichiers plus longs, liens symboliques, droits d'accès…), et éventuellement les extensions Joliet utilisées par les systèmes Windows 95, Windows NT, Windows 2000 et XP (noms de fichiers longs Microsoft). Le prix à payer pour cette amélioration est la perte de quelques centaines de kilo-octets, ce qui est dérisoire étant donné le gain en portabilité. La ligne de commande à utiliser pour créer une image disque est la suivante :

mkisofs  [-J][-r | -R][-hfs | -apple] [-C début,fin [-M disque]] \
     [-V "nom"] -o image répertoires

Les options -r ou -R, -J et -hfs ou -apple permettent respectivement d'utiliser les extensions Rock Ridge, Joliet ou HFS (pour les disques devant être lus sur les Macintosh). Il est possible de faire des images disque hybrides, qui pourront être lues sur plusieurs systèmes d'exploitation différents. La seule contrepartie est la perte de quelques dizaines de kilo-octets, ce qui est dérisoire. La distinction entre l'option -r et l'option -R est que -r modifie les attributs des fichiers Unix afin que le CD puisse être utilisé sur un autre ordinateur que celui sur lequel le CD a été créé. En particulier, le propriétaire et le groupe des fichiers voient leurs valeurs fixées à 0. L'option -V permet de fixer le nom du volume dans l'image. Il est possible de placer ce nom entre guillemets. Cette fonctionnalité est intéressante si ce nom comprend des espaces.

Il est possible de créer des CD multisessions à condition de spécifier l'emplacement de cette session lors de la création de l'image disque. Cela se fait avec l'option -C de mkisofs. Cette option prend en paramètre le numéro du secteur de début et le numéro du secteur de fin de la session à la suite de laquelle la nouvelle session doit être écrite, séparés par des virgules. Si l'on veut également importer la session précédente (c'est-à-dire permettre l'accès aux données des sessions précédentes comme si elles étaient également présentes dans la session à écrire), il faut utiliser l'option -M, à laquelle il faut indiquer le fichier spécial de périphérique du lecteur contenant le disque dont la session doit être importée.

La détermination des secteurs de début et de fin de la session précédente peut être difficile, mais cdrecord est capable d'obtenir cette information avec la commande suivante :

cdrecord dev=graveur -msinfo

Appelé ainsi, cdrecord affiche les secteurs de début et de fin de la dernière session du disque du lecteur spécifié par son option dev, directement dans le format attendu par mkisofs.

L'option -o de mkisofs permet de spécifier le nom du fichier image qui doit être créé. Les paramètres suivant l'option -o constituent la liste des répertoires et des fichiers qui doivent être insérés dans le CD-ROM. Par défaut, chaque répertoire ou fichier indiqué en paramètre est placé dans le répertoire racine du CD-ROM, et l'arborescence des sous-répertoires est respectée. Cependant, il est possible de placer un des répertoires ou fichiers indiqués en paramètre dans un autre répertoire du CD-ROM, à l'aide de la syntaxe suivante :

destination=source

où destination est le répertoire destination du CD-ROM, et source le répertoire ou le fichier source à ajouter à l'image disque. De même, il est possible d'exclure certains sous-répertoires de l'image disque à l'aide de l'option -x :

-x répertoire

Les sous-répertoires du répertoire indiqué seront également supprimés de l'image disque.

Vous pouvez tester votre image disque en la montant par l'intermédiaire du périphérique virtuel du noyau loopback. Il faut pour cela que vous ayez activé la gestion de ce périphérique dans la configuration du noyau. La commande à utiliser est la suivante :

mount -t iso9660 -o ro,loop=/dev/loop0 image /cdrom

où image est le nom de votre fichier image à tester. Cette commande monte le système de fichiers de cette image dans le répertoire /cdrom. La commande umount peut être utilisée pour démonter ce système de fichiers de la manière habituelle.

Lorsque votre image disque est satisfaisante, vous pouvez la graver avec la première ligne de commande suivante :

cdrecord -v dev=graveur speed=n -multi -data image

Vous noterez la présence de l'option -multi, qui permet de demander à cdrecord de créer un disque multisession. Bien entendu, vous pouvez vous passer de cette option si votre disque n'est pas multisession.

La création d'une image disque nécessite d'avoir une place disque égale à la taille de la session à ajouter, ce qui peut être contraignant. Sur les systèmes suffisamment puissants, il est possible de créer l'image disque et de la graver à la volée en créant un tube entre mkisofs et cdrecord. Dans ce cas, il ne faut pas donner de nom à l'image disque dans la ligne de commande de mkisofs, et utiliser l'option - dans la ligne de commande de cdrecord pour lui demander de prendre les données sur son entrée standard. Malheureusement, cette technique n'est pas utilisable facilement pour les disques multisessions, parce que la lecture des informations de la session précédente peut se faire en même temps que le début du gravage. Pour résoudre ce problème, il faut utiliser l'option -waiti de cdrecord, qui lui demande d'attendre l'arrivée des premières données dans le tube avant d'ouvrir le fichier spécial de périphérique du graveur. La ligne de commande complète devient alors assez complexe, comme vous pouvez en juger :

mkisofs -r -M périphérique -C `cdrecord dev=graveur -msinfo` \
  fichiers |  cdrecord -v dev=graveur speed=vitesse -multi -waiti -

Les commandes présentées ci-dessus ne permettent pas de travailler avec des CD audio. Pour extraire les données audio d'un CD, vous devrez utiliser le programme cdda2wav» :

cdda2wav [-H] -B nom [-tdébut[+fin]] -O wav dev=graveur

L'option -H permet d'éviter la création des fichiers d'information .inf sur les pistes extraites par cdda2wav. L'option -B permet d'utiliser le nom nom complété d'un numéro pour les fichiers son créés. Les pistes seront donc stockées dans des fichiers portant les noms nom_01, nom_02, etc. L'option -t permet d'indiquer la piste début et la piste fin afin de sélectionner les pistes dont les données audio doivent être extraites. Si la piste de fin n'est pas précisée, toutes les pistes depuis la piste de début jusqu'à la dernière piste du CD seront extraites. De même, si la piste de début n'est pas précisée, l'extraction commencera à partir de la première piste. L'option -O permet d'indiquer le type de fichier de sortie, wav indique ici que les fichiers créés seront au format WAV des fichiers son de Windows. Il est également possible d'utiliser le type de fichier raw, avec lequel les fichiers seront prêts à être gravés tels quels. Enfin, l'option dev permet de spécifier le périphérique à utiliser pour lire les données audio. La syntaxe de cette option est la même que celle utilisée par cdrecord.

Le gravage des pistes audio peut être réalisé avec la commande suivante :

cdrecord -dummy -v dev=graveur speed=n -nofix -audio  piste1.wav \
    piste2.wav …

L'option -nofix permet ici d'éviter de fermer la session. Elle doit être utilisée si l'on désire rajouter des pistes audio sur le CD-ROM ultérieurement. Si, en revanche, elle est omise, cdrecord fermera automatiquement la session après l'écriture de la dernière piste, et plus aucune donnée ne pourra être ajoutée. La commande suivante vous permettra de fixer le disque a posteriori :

cdrecord -dummy -v dev=graveur speed=n -fix

Enfin, si vous disposez d'un graveur de CD réinscriptible, vous pourrez utiliser la commande suivante pour effacer un CDRW :

cdrecord -dummy -v dev=graveur -blank=fast

où graveur représente toujours le périphérique du graveur.

Il est peu probable que vous ayez à utiliser ces commandes directement, car il existe de nombreux programmes graphiques capables de les piloter de manière conviviale (k3b, gcombust, xcdroast, etc.). Il est vivement recommandé d'en installer un et de l'utiliser. Ils sont relativement simples d'emploi et leur utilisation ne devrait pas poser de problème particulier.

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'échantillonnage 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 quelle 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 relatifs à 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

Si vous désirez utiliser les pilotes OSS, le module à utiliser pour ce type de carte se nomme es1371, ce qui fait que le fichier de configuration /etc/modprobe.conf se réduit dans ce cas à :

# La première carte son est gérée par le module es1371 :
alias sound-slot-0 es1371

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és 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 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 :

alsactl restore

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 :

options snd-cmipci fm_port=0x388 mpu_port=0x300

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 :

snd-cmipci.index=0 snd-cmipci.fm_port=0x388 snd-cmipci.mpu_port=0x300

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 :

sbiload -p65:0 --opl3 std.o3 drums.o3

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 :

sbiload -l

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_port au 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 :

sfxload /usr/lib/synthgm.sbk

(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-alsaseq

Une fois cela fait, vous pourrez générer l'exécutable avec la commande suivante :

make

et l'installer avec la commande :

make install

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 :

timidity fichier

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.

La configuration du port parallèle sous Linux est relativement automatique. Il suffit en effet, dans le programme de configuration du noyau, d'activer les options « Parallel port support », « PC-style hardware », « Use FIFO/DMA if available » et « IEEE 1284 transfer modes » du menu « Parallel port support ». Si vous désirez connecter une imprimante sur votre port parallèle, ce qui est généralement le cas, il vous faudra également activer l'option « Parallel printer support » du menu « Character devices ». De même, si vous désirez connecter un disque dur, un lecteur de CD-ROM ou un lecteur de bande sur votre port parallèle, vous devrez activer l'option « Parallel port IDE device support » du menu « Block devices », ainsi qu'au moins une des sous-options pour le type de périphérique à utiliser et un des modules de prise en charge des protocoles de communication sur port parallèle.

Pour des raisons de compatibilité, le gestionnaire de ports parallèles utilise par défaut une interrogation périodique pour déterminer l'état des ports. Cela consomme généralement des ressources de calcul, mais c'est une technique fiable. Toutefois, si votre matériel le permet, il est possible de le configurer pour utiliser une interruption matérielle, et soulager ainsi le processeur de cette tâche. Nous allons donc voir comment configurer le port parallèle ci-dessous.

Afin d'utiliser une interruption matérielle pour le port parallèle, il est nécessaire de spécifier explicitement la ligne de cette interruption. Cela peut se faire avec l'option irq du module prenant en charge le port parallèle. Sur les ordinateurs de type PC, le nom de ce module est « parport_pc », mais, comme on l'a vu dans la Section 8.1.1, le noyau demande toujours le chargement du module « parport_lowlevel » pour des raisons de portabilité. Il faut donc définir un alias dans le fichier de configuration /etc/modprobe.conf.

Outre la ligne d'interruption à utiliser, le module parport_pc peut prendre en paramètre une autre option permettant d'indiquer le port d'entrée / sortie qu'il doit utiliser pour accéder au port parallèle. Cette option est l'option io. En général, le port utilisé est le port numéro 378h et la ligne d'interruption est souvent la 7. Les options suivantes doivent donc être définies dans le ficher modprobe.conf pour obtenir un fonctionnement optimal du port parallèle sous Linux :

alias parport_lowlevel parport_pc
options parport_pc io=0x378 irq=7

D'autres options pourront être définies dans le fichier de configuration modprobe.conf pour prendre en charge les périphériques de type bloc connectés sur port parallèle. Cela est inutile pour les imprimantes connectées sur le port parallèle.

Si l'on désire intégrer le gestionnaire de périphérique du port parallèle dans le noyau et faire en sorte qu'il utilise les paramètres détectés automatiquement pour ce port, la solution la plus simple est de fournir l'option parport du noyau et de lui affecter la valeur auto :

parport=auto

Cela activera automatiquement l'utilisation de la ligne d'interruption du port parallèle. Les autres paramètres du port parallèle peuvent être trouvés dans le fichier kernel-parameters.txt de la documentation du noyau.

Les ports série fournis en standard sur les cartes mères sont détectés et configurés automatiquement par le noyau lorsque l'ordinateur démarre. Pour que cela fonctionne, il suffit que l'option « Standard/generic (8250/16550 and compatible UARTs) serial support » du menu « Character devices » soit activée.

Cela dit, il se peut que votre ordinateur contienne un port série non standard, ou que vous ayez à sélectionner des options spécifiques pour votre matériel. Il vous faudra, dans ce cas, activer les options complémentaires relatives aux ports série dans le menu « Character devices ».

Le noyau n'est, en général, capable d'initialiser que les ports série standards intégrés dans les cartes mères (c'est-à-dire les ports COM1 à COM4), auxquels on accède, sous Linux, par l'intermédiaire des fichiers spéciaux de périphériques /dev/ttyS0 à /dev/ttyS3. Pour les autres ports série, il peut être nécessaire de les initialiser manuellement, par exemple dans un fichier de configuration lancé au démarrage du système.

Cette initialisation se fait à l'aide de la commande setserial, dont la syntaxe simplifiée est la suivante :

setserial fichier [uart type] [port adresse] [irq ligne]

où fichier est le fichier spécial de périphérique permettant d'accéder au port série à initialiser, type est le type de port série utilisé, adresse est son adresse d'entrée / sortie et ligne est la ligne d'interruption qu'il utilise. La commande setserial dispose de nombreuses autres options. Je vous invite à en lire la page de manuel pour les découvrir.

Une fois le port série correctement initialisé, il est possible de fixer les paramètres de la ligne de communication avec la commande stty. Comme on l'a déjà vu précédemment, cette commande permet de fixer tous les paramètres des lignes de communication des terminaux et non seulement les paramètres des lignes série, et elle dispose donc d'un grand nombre d'options. Nous n'allons nous intéresser ici qu'aux options utilisées pour les lignes série. La page de manuel de stty pourra être consultée pour plus de détails.

La syntaxe à utiliser pour lire les paramètres de communication d'une ligne série est la suivante :

stty -a -F périphérique

où périphérique est le fichier spécial de périphérique de la ligne. Si vous exécutez cette commande, vous constaterez qu'un grand nombre d'informations est donné. Les informations les plus utiles sont sans doute speed, qui donne la vitesse de la ligne série, csN, qui donne le nombre N de bits de données par caractère, [-]parenb, qui indique si un bit de parité est utilisé ou non (auquel cas le caractère '-' est présent), [-]parodd, qui indique le type de parité utilisée (paire ou impaire selon la présence ou l'absence du caractère '-'), et [-]cstopb, qui indique le nombre de bits de stop utilisés (un ou deux selon la présence ou l'absence du caractère '-'). L'option [-]crtscts indique si le contrôle de flux matériel est utilisé ou non. À titre d'exemple, voici une sortie typique de la commande stty sur le premier port série :

speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <indéfini>;
eol2 = <indéfini>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl
ixon -ixoff -iuclc -ixany -imaxbel opost -olcuc -ocrnl
onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

Les mêmes options peuvent être utilisées pour fixer les paramètres de la ligne de communication. La ligne de commande à utiliser est alors la suivante :

stty -F périphérique options

Il existe une différence cependant : le paramètre permettant de fixer la vitesse de la ligne est décomposé en deux options ispeed pour le flux de données entrant et ospeed pour le flux de données sortant. On peut fixer la vitesse de la ligne avec l'option ispeed. Par exemple, pour faire passer la ligne de communication du deuxième port série à 115200 bauds, 7 bits de données, un bit de stop et une parité paire, il faut utiliser la ligne de commande suivante :

stty -F /dev/ttyS1 ispeed 115200 cs7 -cstopb parenb -parodd

Il est important de bien configurer les ports série avec les mêmes paramètres de ligne que ceux utilisés par les périphériques qui y sont connectés pour que la communication se fasse correctement.

La prise en charge du bus IEEE1394 au niveau du noyau est réalisable par l'intermédiaire des options du menu « IEEE 1394 (FireWire) support (EXPERIMENTAL) ». Comme le support des périphériques IEEE1394 sous Linux en est encore à ses balbutiements, ce menu ne peut être accédé que si l'on a activé l'option « Prompt for development and/or incomplete code/drivers » du menu « Code maturity level options ». Les principales options utilisables sont les suivantes :

• l'option « IEEE 1394 (FireWire) support (EXPERIMENTAL) », qui est l'option principale qui active toutes les autres options. Il faut donc impérativement activer cette option et répondre 'Y' ;
• l'option « Texas Instruments PCILynx support », qui permet de prendre en charge les cartes IEEE1394 basées sur la puce PCILynx de Texas Instrument. Ce ne sont pas les cartes les plus couramment utilisées, aussi la réponse recommandée est-elle 'N'. Si vous activez cette option, vous pourrez configurer des paramètres complémentaires du gestionnaire de périphériques avec les options « Use PCILynx local RAM » (utilisation de la mémoire embarquée sur la carte PCI) et « Support for non-IEEE1394 local ports » (utilisation de fonctionnalités complémentaires non FireWire de ces cartes) ;
• l'option « OHCI-1394 support », qui active la prise en charge des périphériques IEEE1394 compatible OHCI (abréviation de l'anglais « Open Host Controller Interface ), qui sont les périphériques les plus courants à présent. La réponse recommandée est 'Y' ;
• l'option « OHCI-1394 Video support », qui permet de prendre en charge les caméras vidéo numériques. Cette option ajoute également une fonctionnalité intéressante qui permet aux programmes de partager les données avec le gestionnaire de périphériques directement. Cela permet d'éviter qu'une copie de ces données ne soit réalisée entre la mémoire du noyau et la mémoire de l'application et d'obtenir ainsi de meilleures performances. La réponse recommandée est bien évidemment 'Y'. Cette option n'est toutefois disponible que pour les périphériques OHCI ;
• l'option « SBP-2 support (Harddisks, etc.) », qui permet de prendre en charge les disques durs et les lecteurs de DVD connectés sur bus IEEE1394. Ces lecteurs apparaissent alors comme des périphériques SCSI standards et pourront être montés via l'un des périphériques /dev/sdx ;
• l'option « Raw IEEE1394 I/O support », qui permet aux applications de communiquer directement avec le bus IEEE1394 par l'intermédiaire d'un fichier spécial de périphérique. Cette option est nécessaire au bon fonctionnement de la plupart des applications IEEE1394 et la réponse recommandée est donc 'Y' ;
• l'option « Excessive debugging output », qui active l'émission de messages de traces pour toutes les données survenant sur le bus IEEE1394. Cette option saturera vos fichiers de traces très vite et n'est réellement utile que pour les développeurs, aussi faut-il répondre 'N'.

Comme pour tous les périphériques sous Linux, les fonctionnalités IEEE1394 du noyau seront accessibles par l'intermédiaire de fichiers spéciaux de périphériques situés dans le répertoire /dev/. Les fonctionnalités vidéo seront accédées par l'intermédiaire d'un fichier spécial de périphérique de type caractère et de code majeur 172. De même, l'interface de données brute activée par l'option « Raw IEEE1394 I/O support » est exposée par l'intermédiaire d'un fichier spécial de périphérique de type caractère et de code majeur 171. Vous devrez donc créer ces fichiers spéciaux à l'aide des deux commandes suivantes :

mknod /dev/raw1394 c 171 0
mknod -m 666 /dev/video1394 c 172 0

Le numéro de code mineur est utilisé pour distinguer les différents ports IEEE1394 présents dans la machine. Les lignes de commandes précédentes ne montrent que la manière de créer les fichiers spéciaux de périphériques que pour le premier port IEEE1394.

Les fonctionnalités IEEE1394 peuvent être utilisées par les applications directement par l'intermédiaire des fichiers spéciaux de périphériques /dev/raw1394 et /dev/video1394, mais quasiment aucune ne le fait. En effet, des bibliothèques spécifiques ont été écrites afin de fixer les interfaces de programmation de Linux avec ces applications. Il est donc nécessaire d'installer ces bibliothèques pour pouvoir utiliser les périphériques IEEE1394.

Il est encore rare que ces bibliothèques soient installées par les distributions, certainement parce qu'elles sont encore en cours de développement. Leur installation nécessite donc de les compiler soi-même, ce qui est une tâche facile si on sait le faire, mais qui peut effrayer un débutant. Rappelons une fois de plus que le support des périphériques IEEE1394 sous Linux est encore expérimental.

La bibliothèque de programmes la plus importante est celle qui permet d'utiliser la fonctionnalité d'accès direct aux périphériques IEEE1394 par l'intermédiaire du fichier spécial de périphérique /dev/raw1394. Les fichiers sources de cette bibliothèque peuvent être trouvés sur le site du projet libraw1394. Une autre bibliothèque utilisée par les programmes vidéo est la bibliothèque libavc1394. Cette bibliothèque permet en effet aux programmes de piloter les caméscopes numériques par l'intermédiaire du bus IEEE1394. Enfin, les programmes d'édition vidéo peuvent avoir besoin de la bibliothèque libdv, qui permet de manipuler les données au format DV (c'est-à-dire le format de données utilisé par la plupart des caméscopes numériques). Cette bibliothèque ne fait pas à proprement parler partie des bibliothèques permettant de communiquer avec les périphériques IEEE1394, mais elle est extrêmement utile.

La compilation de ces bibliothèques se fait classiquement avec les commandes suivantes :

./configure --prefix=/usr
make

à partir du répertoire des sources. Celui-ci pourra être extrait des archives à l'aide de la commande tar xzf archive, où archive est le nom de l'archive en question. Une fois compilées, les bibliothèques pourront être installées avec la commande :

make install

Ces opérations ne devraient pas poser de problème particulier. Consultez le Chapitre 7 pour plus de détails sur ces opérations.

Une fois ces bibliothèques installées, vous devriez pouvoir installer et utiliser des applications dédiées aux périphériques IEEE1394, comme dvgrab (outil de capture vidéo), kino ou broadcast2000 (outils d'édition de séquences vidéo). Force est de reconnaître que ces programmes sont très loin d'être finis et réellement difficiles à utiliser.