Page suivante Page précédente Table des matières

8. Le tampon graphique (frame buffer) dans les noyaux 2.2.x.

Par Larry Ayers

Publié dans le numéro 36 de la Linux Gazette, janvier 1999

8.1 Introduction.

La nouvelle version majeure du noyau de Linux, la 2.2.0, est en train de sortir au moment où j'écris ces lignes. Elle est riche de nombreuses fonctionnalités nouvelles, parmi lesquelles la possibilité d'utiliser un nouveau type de périphérique pour gérer la console : le tampon graphique. Il est représenté par /dev/fb[0-7]. S'il n'apportera probablement pas grand chose sur l'architecture Intel, il pourra être très utile sur Alpha, Sparc ou PPC. En effet, il s'agit d'un gestionnaire de console indépendant du matériel.

Voici ce qu'écrit Geert Uytterhoeven, le programmeur belge responsable du développement du tampon graphique, en guise de présentation de ce périphérique dans les sources du noyau :

Le tampon graphique est une interface avec le matériel video. Il représente le tampon contenant les images, et permet aux applications d'accéder au matériel via un protocole bien défini, indépendant du matériel, ce qui évite au logiciel d'avoir à s'occuper de ce qui se passe au bas-niveau.

Les utilisateurs d'Intel peuvent déjà changer la résolution de leur console texte, que ce soit en utilisant l'option video=ask de LILO, ou grâce au logiciel SVGATextMode. Bien que je sois arrivé à utiliser ma console en 116x34, je n'ai pas pu m'empêcher de regarder ce que faisaient les nouveaux pilotes de console présents dans les versions beta du noyau. Comme je dispose d'une Matrox Mystique, et que le tampon graphique supporte les cartes Matrox, j'ai sauté le pas sans hésiter.

8.2 Aide pour l'installation.

Lors de mon premier essai, j'ai vu, en lisant les messages de démarrage, que la carte video était détectée, et j'ai vu apparaître le pingouin de Linux dans le coin supérieur droit de l'écran. Mais la console restait dans le bon vieux mode 80x25. En lisant la documentation, j'ai appris l'existance de fbset, un petit programme écrit par Geert Uytterhoeven et Roman Zippel, qui affiche ou modifie la résolution du tampon graphique. C'est son installation qui crée les fichiers de périphérique /dev/fb[0-7], nécessaires à son utilisation. Il peut être téléchargé ici.

J'ai aussi trouvé dans les sources du noyau un document appelé matroxfb.txt, écrit par Petr Vandrovec, l'auteur du pilote pour les cartes Matrox. Il décrit les résolutions possibles avec les cartes Matrox. Pour les autres cartes graphiques respectant la norme VESA 2.0, il faut consulter vesafb.txt.

On peut indiquer au noyau la résolution souhaitée de deux façon. On peut d'abord la lui indiquer via LILO, au démarrage. Supposons que votre noyau principal, fiable, est le premier dans /etc/lilo.conf, et que celui compilé avec le tampon graphique vient ensuite, sous le nom de bzImage-2.2. Lorsque s'affiche l'invite de LILO, appuyez sur shift, et tapez, par exemple : LILO bzImage-2.2 video=matrox:vesa:0x188.

L'écran passe à cette résolution (ici 960x720), si elle est supportée, un peu après les premiers messages de démarrage. Voici un exemple de ce que le noyau affichera :

matroxfb: Matrox Mystique (PCI) detected
matroxfb: 960x720x8bpp (virtual: 960x4364)
matroxfb: framebuffer at 0xE0000000, mapped to 0xc4807000, size 4194304
Console: switching to colour frame buffer device 120x45
fb0: MATROX VGA frame buffer device

Si cette résolution vous convient, vous pouvez modifier /etc/lilo.conf pour y ajouter une commande indiquant automatiquement au noyau la résolution à utiliser. Vous devriez ajouter, par exemple : append="video=matrox:vesa:392". Attention, les "" sont nécessaires, et la valeur hexadécimale (0x192) doit être remplacée par sa valeur décimale, soit ici 392. LILO n'accepte en effet pas les nombres hexadécimaux dans /etc/lilo.conf.

Après le démarrage, on peut utiliser fbset pour changer la résolution. Pour connaître les modes video valides, on peut se reporter aux fichiers de configuration de X, ou faire comme moi, et essayer plusieurs valeurs hexadécimales au lancement de LILO, puis utiliser fbset sans argument, pour afficher le mode video actuel. Le format adopté est celui utilisé dans le fichier /etc/fb.modes, encore inexistant. Voici un exemple :

kbdmode "name"
    # D: 56.542 MHz, H: 45.598 kHz, V: 59.998 Hz
    geometry 960 720 960 4364 8
    timings 17686 144 24 28 8 112 4
endmode

La plupart de ces modes peuvent être copiés tel quel dans /etc/fb.modes, en choisissant des noms faciles à retenir pour les différents modes. Il est utile d'avoir un mode noir et blanc de base, en utilisant soit un de ceux proposé dans la documentation, soit en copiant ce qu'affiche un fbset -depth 0. Les programmes qui font appel à la SVGAlib ne fonctionneront pas correctement avec plus de couleurs. Une fois qu'une entrée a été ajoutée dans /etc/fb.modes, on peut changer dynamiquement de mode en tapant fbset nom_du_mode.

8.3 Le tampon graphique et X.

La plupart des lecteurs doivent se demander si X va démarrer depuis une console utilisant un tampon graphique. Tout est relatif. Certaines combinaisons de serveurs X et de cartes graphiques posent des problèmes, surtout pour passer de X à la console, et vice versa. Ces problèmes existaient déjà avec SVGATextMode. Dans mon cas, avec XFree86 3.3.3 et une carte Matrox, tout a bien fonctionné.

Il y a un serveur X spécial, XF68_FBDev, disponible dans les sources de XFree86 à partir de la version 3.2. Il n'y a pas de version précompilée, et le serveur n'est pas accéléré. Il ne devrait être utile qu'aux utilisateurs de matériel un peu rare, comme les PPC.

8.4 Conclusion.

La majorité des utilisateurs de Linux ne va pas utiliser le tampon graphique dans un futur proche. S'il présente des avantages avec certaines cartes, il faut du temps pour le configurer correctement, et il ne sert à rien pour les utilisateurs qui se servent principalement de X Window. S'il est intégré au noyau, c'est que le code du tampon graphique est indépendant du matériel, contrairement à l'essentiel du pilote de console utilisé actuellement. En plus, XFree86 4.0, qui sortira peut-être cette année, devrait mieux supporter le tampon graphique.

_______________________________________________________________________________

Copyright © 1999, Larry Ayers - Publié dans le n°36 de la Linux Gazette, janvier 1999.

Adaptation française de Marc Simon


Page suivante Page précédente Table des matières