alex.buell@tahallah.clara.co.ukRevision history
19990607 - Release of 1.0
19990722 - Release of 1.1
20000222 - Release of 1.2
Merci aux personnes dont les noms suivent pour avoir aid� � l'am�lioration du HOWTO Framebuffer.
jeff@planetfall.comf.devereux@cs.ucl.ac.ukehliar@futurniture.semarty@ehabitat.demon.co.uksimon@koala.iedavid@kalifornia.comcblack@cmpteam4.unil.chnbecker@fred.netrct@gherkin.sa.wlk.commarius.hjelle@roman.uib.nojcassidy@misc.dyn.ml.organdreas.trottmann@werft22.comlech7@lech.pse.pltiensivu@pilot.msu.edujanfrode@ii.uib.nofrederick.a.niles@gsfc.nasa.gov qui a
accept� que son Mini-HOWTO Multi-Head soit inclus dans ce HOWTO.
Merci aux personnes suivantes pour avoir compil� les versions libc5/glibc2
du gestionnaire XF86_FBdev pour X11 sur les architectures Intel :
brion@pobox.comkraxel@cs.tu-berlin.debien s�r l'auteur du code :
Roman.Hodek@informatik.uni-erlangen.deschwab@issan.informatik.uni-dortmund.deGeert.Uytterhoeven@cs.kuleuven.ac.beroman@sodom.obdg.depavel@atrey.karlin.mff.cuni.czkraxel@cs.tu-berlin.demiguel@nuclecu.unam.mxcarter@compsci.bristol.ac.ukwjr@cs.cornell.edujds@kom.auc.dkjsk@mojave.stanford.edumichal.rehacek@st.mff.cuni.eduzaitcev@lab.ipmce.sudavem@dm.cobaltmicro.comdjhr@tadpole.co.ukmj@ucw.czdan@debian.orgcore@ggi-project.orgecd@skynet.bejj@ultra.linux.czphilb@gnu.orgUn tampon de m�moire vid�o d�finit une abstraction logicielle d'acc�s aux p�riph�riques vid�o. Il correspond � la m�moire d'affichage de certains contr�leurs graphiques et propose une interface unifi�e aux logiciels qui n'ont alors plus � se soucier des d�tails de bas niveau relatifs au mat�riel [Extrait du fichier framebuffer.txt �crit par Geert Uytterhoeven's. Se reporter aux sources du noyau]
Le logo ! Plus s�rieusement, on dispose d'une interface ind�pendante de l'architecture mat�rielle. Les gestionnaires de console des machines de type Intel sont rest�s radicalement diff�rents de ceux des autre plate-formes jusqu'� une phase de d�veloppement avanc�e des noyaux 2.1.x. Avec l'introduction dans le noyau 2.1.109 de cette interface, les choses se sont am�lior�es : la gestion des consoles sur PC s'est uniformis�e, les consoles en mode graphique affichant le logo du pingouin ont fait leur apparition et le code s'est propag� aux autres types de machines. Notez que les noyaux 2.0.x ne disposent pas du gestionnaire d'acc�s � la m�moire vid�o. Peut-�tre quelqu'un finira-t-il par int�grer le code des versions 2.1.x dans ces noyaux. Le portage version 0.9.x pour les machines m68k font exception en ce qu'elles int�grent le pilote. Avec la disponibilit� des noyaux 2.2.x, le gestionnaire de m�moire vid�o s'av�re stable et robuste. Vous devriez l'utiliser si votre carte vid�o le supporte et si vous employez un noyau 2.2.x. La question ne se pose pas si vous travaillez avec un 2.0.x, du moins sur un PC.
Le gestionnaire de m�moire vid�o offre des possibilit�s int�ressantes si on pr�cise quelques options au noyau lors du d�marrage. Certaines sont sp�cifiques � un type de carte donn�.
video=xxx:off - d�sactive l'auto-d�tection d'un pilotevideo=map:octal-number - associe des consoles virtuelles ( VC )
� un gestionnaire de m�moire vid�o
video=map:01 VC0 est associ�e � FB0, VC1 � FB1, VC2 � FB0, VC3
� FB1...video=map:0132 VC0 est associ�e � FB0, VC1 � FB1, VC2 � FB3, VC4
� FB2, VC5 � FB0...La d�tection des gestionnaires de m�moire vid�o a lieu dans un ordre fix�
au niveau du noyau. Vous pouvez l'alt�rer gr�ce � l'option video=xxx
qui permet de forcer la d�tection de certains p�riph�riques avant les autres.
Vesafb est un gestionnaire de m�moire vid�o sur compatible PC d�di� aux cartes cartes graphiques conformes aux sp�cifications VESA 2.0. Son fonctionnement est li� de pr�s aux gestionnaires de m�moire vid�o g�n�riques du noyau.
Vesafb permet le recours aux modes graphiques sur PC pour l'utilisation des consoles textes en point par point. Vesafb autorise �galement l'affichage d'un logo et c'est vraisemblablement ce pour quoi vous voulez vous en servir :o)
On ne peut malheureusement pas utiliser vesafb avec des cartes VESA 1.2. En effet, ces cartes n'utilisent pas un adressage lin�aire. Par ce terme, on entend que tous les octets de la m�moire vid�o sont accessibles � un instant donn�. Historiquement, les anciennes cartes vid�o ne rendaient la m�moire graphique disponible qu'au travers d'une fen�tre de 64 ko qui correspondait � la taille de la plus grande zone de m�moire contig�e g�rable directement par le microprocesseur (d'o� les limitations des cartes CGA/EGA). Quelqu'un �crira peut-�tre un gestionnaire de p�riph�riques vesafb12 pour ce type de cartes, mais il consommera une m�moire par ailleurs pr�cieuse pour le noyau et �a restera de toute fa�on un sale bricolage. :o(
Il existe cependant un moyen d�tourn� d'acc�der aux fonctionnalit�s VESA 2.0 sur une carte VESA 1.2. Peut-�tre pouvez vous charger depuis le DOS un programme de type TSR qui, utilis� conjointement avec loadlin, aidera � configurer la carte pour les modes graphiques voulus. Cela ne marchera pas toujours. Ainsi, certaines cartes de chez Cirrus Logic, telles les VLB 54xx, se retrouvent � une position en m�moire (par exemple entre 15 et 16 Mo) qui en interdit l'utilisation sur les syst�mes munis de plus de 32 Mo de m�moire. Rien de r�dhibitoire si on dispose d'un BIOS permettant de ne pas affecter de m�moire entre 15 et 16 Mo ("Memory Hole") mais il m'a sembl� comprendre que Linux n'aime pas �a. Si l'exp�rience vous tente, vous pouvez essayer UNIVBE (disponible sur l'Internet).
Vous pouvez aussi essayer divers patches noyaux. Il en existe notamment pour les anciennes cartes S3 telles la S3 Trio ou la Virge qui se conforment � la norme VESA 1.2. Les patches sont disponibles via : ftp://ccssu.crimea.ua/pub/linux/kernel/v2.2/unofficial/s3new.diff.gz>.
A supposer que vous utilisiez menuconfig, vous devrez passer par les �tapes suivantes : Dans le menu "Console drivers" :
Si votre processeur (de type x86) supporte le MTRR, activez le. Il permet d'acc�l�rer les copies entre la m�moire syst�me et la carte graphique. Vous pouvez naturellement le mettre en marche une fois la console op�rationnelle. IMPORTANT : pour les noyaux 2.1.x, activez le choix des fonctionnalit�s exp�rimentales via le menu ``Code Maturity Level''. Ceci est inutile pour les noyaux 2.2.x.
Le support des composants VGA (en mode texte) - vgafb - appartenait � la liste ci-dessus mais il en a �t� supprim� en raison de son obsolescence. Il dispara�tra sous peu. S�lectionnez plut�t "VGA Text Console".
V�rifiez bien que le support "Mac variable bpp packed pixel" n'est pas activ�. [En 2.2.111/112, il semblerait qu'il le soit si "Advanced Low Level Drivers" l'est. Ce n'est plus le cas en 2.1.113] Les fontes peuvent �galement �tre stock�es en m�moire mais rien n'y oblige et l'emploi de setfont du paquetage kbd-0.99 reste possible pour charger les fontes ad�quates (reportez vous � la section relative aux fontes).
Assurez vous que rien n'est modularis�. [J'ai des doutes quand aux possibilit�s de modularisation de l'ensemble - corrections bienvenues]
Vous devrez ensuite cr�er les p�riph�riques associ�s au gestionnaire de m�moire vid�o dans le r�pertoire /dev. Pour le premier, il vous suffit de taper
# mknod /dev/fb0 c 29 0
# mknod /dev/fb1 c 29 32
# mknod /dev/fb7 c 29 224
Voici mon lilo.conf personnel :
# LILO configuration file
boot = /dev/hda3
delay = 30
prompt
vga = ASK # L'utilisateur devra entrer le mode
image = /vmlinuz
root = /dev/hda3
label = Linux
read-only # Les systemes de fichiers autres que UMSDOS doivent etre montes
# en lecture seule pour la phase de verification
Red�marrez le noyau et essayez comme test d'entrer 0301 au prompt VGA. Vous devriez vous retrouver en 640x480 sur 256 couleurs avec un d�licieux petit logo de ping^H^H^H^Hmanchot.
A l'invite LILO, vous DEVEZ fournir un chiffre sous la forme d'un ``0'' suivi de 3 digits sans ``x'' hexad�cimal. Si LILO fournit directement l'argument au noyau, ceci n'est pas n�cessaire.
Une fois que tout marche convenablement, vous pouvez explorer les diff�rents modes (voir plus bas) et une fois choisi celui qui vous convient, il sera temps de le fixer via le param�tre ``VGA=x'' du fichier de configuration de lilo. La table plus bas vous fournira le nombre correspondant au mode. Par exemple, pour du 1280x1024 en 256 couleurs, vous emploierez ``VGA=0x307'' et relancerez lilo. Le reste se trouve dans les HOWTO relatifs � lilo et � loadlin.
NOTE ! vesafb n'active pas automatiquement le d�filement vers l'arri�re. Vous devez le pr�ciser au noyau : video=vesa:ypan ou video=vesa:ywrap. Les deux font la m�me chose mais de fa�on un peu diff�rente. ywrap est bien plus rapide qu'ypan mais risque de ne pas fonctionner sur des cartes VESA 2.0 ne respectant pas tout � fait les sp�cifications. L'option n'est disponible qu'� partir du noyau 2.1.116. Les noyaux pr�c�dents ne permettent pas le d�filement vers l'arri�re.
Cela d�pend de votre carte graphique, en particulier de la quantit� de m�moire dont elle dispose. A vous de voir quels sont les modes qui fonctionnent le mieux.
La table suivante fournit les num�ros des modes que vous pouvez passer � l'invite VGA (en fait les indices se sont vus ajouter 0x200 afin de s'y retrouver plus facilement dans la table).
Couleurs 640x400 640x480 800x600 1024x768 1152x864 1280x1024 1600x1200 ---------+-------------------------------------------------------------- 4 bits | ? ? 0x302 ? ? ? ? 8 bits | 0x300 0x301 0x303 0x305 0x161 0x307 0x31C 15 bits | ? 0x310 0x313 0x316 0x162 0x319 0x31D 16 bits | ? 0x311 0x314 0x317 0x163 0x31A 0x31E 24 bits | ? 0x312 0x315 0x318 ? 0x31B 0x31F 32 bits | ? ? ? ? 0x164 ?8 bits = 256 couleurs, 15 bits = 32768 couleurs, 16 bits = 65536 couleurs, 24 bits = 16,8 millions de couleurs, 32 bits : la m�me chose qu'en 24 bits mais les 8 bits restant peuvent servir � diverses fins et l'ensemble s'adapte parfaitement aux bus 32 bits PCI/VLB/EISA. Les modes suppl�mentaires sont � la discr�tion du fabricant puisque la sp�cification VESA 2.0 s'arr�te au mode 0x31f. Il vous faudra s�rement t�tonner pour les trouver.
Si vous disposez d'une carte Matrox, vous emploierez le pilote matroxfb au lieu de vesafb. Matroxfb g�re les Mystique Millenium I, II ainsi que les G100 et G200. Il permet aussi d'avoir plusieurs cartes dans la m�me machine. La configuration d'une carte Matrox passe par les �tapes suivantes :
Mise � jour du BIOS Matrox que vous trouverez � http://www.matrox.com/mgaweb/drivers/ftp_bios.htm>. Attention, vous aurez besoin du DOS pour proc�der � la mise � jour.
Allez dans le menu ``Code Maturity Level'' et activez l'option suivante :
Dans le menu ``Console Drivers'', s�lectionnez :
Recompilez votre noyau et modifiez le fichier /etc/lilo.conf.
Inspirez vous du mien, vous irez plus vite.
# Fichier de configuration de LILO boot = /dev/hda3 delay = 30 prompt vga = 792 # N�cessaire pour une r�initialisation dans un �tat normal # Linux bootable partition config begins image = /vmlinuz append = "video=matrox:vesa:440" # On bascule sur le pilote Matroxfb root = /dev/hda3 label = Linux read-only # Non-UMSDOS filesystems should be mounted read-only for checking
Vous devrez ensuite cr�er les p�riph�riques associ�s au gestionnaire de m�moire vid�o dans le r�pertoire /dev. Pour le premier, il vous suffit de taper :
# mknod /dev/fb0 c 29 0
# mknod /dev/fb1 c 29 32
# mknod /dev/fb7 c 29 224
Les cartes de type Permedia ne sont pas support�es par le pilote vesafb. Heureusement, il existe un gestionnaire de m�moire vid�o sp�cifique aux cartes Permedia. En supposant que vous employez menuconfig pour param�trer le noyau avant une compilation, ex�cutez les instructions suivantes :
Allez dans le menu ``Code Maturity Level'' et activez l'option suivante :
Dans le menu ``Console Drivers'', s�lectionnez :
Recompilez votre noyau et modifiez le fichier /etc/lilo.conf.
Inspirez vous du mien pour aller plus vite.
# Fichier de configuration de LILO boot = /dev/hda3 delay = 30 prompt vga = 792 # N�cessaire pour une r�initialisation dans un �tat normal # Linux bootable partition config begins image = /vmlinuz append = "video=pm2fb:mode:1024x768-75,font:SUN12x22,ypan" # then switch to pm2fb root = /dev/hda3 label = Linux read-only # Non-UMSDOS filesystems should be mounted read-only for checking
La ligne ``pm2fb:mode:1024x768-75,font:SUN12x22,ypan'' indique que le pilote op�rera dans une r�solution de 1024 par 768 � 75Hz avec les fontes SUN 12 par 22 (si vous les avez incluses). Ypan autorise le d�filement. Vous pouvez employer un autre mode.
Vous devrez ensuite cr�er les p�riph�riques associ�s au gestionnaire de m�moire vid�o dans le r�pertoire /dev. Pour le premier, il vous suffit de taper
# mknod /dev/fb0 c 29 0
# mknod /dev/fb1 c 29 32
# mknod /dev/fb7 c 29 224
Pour davantage de renseignements concernant les fonctionnalit�s du pilote Permedia, consultez http://www.cs.unibo.it/~nardinoc/pm2fb/index.html>.
video=pm2fb:[option[,option[,option...]]]
o� vous disposez des options suivantes :
Remarque : les informations qui suivent ne viennent pas de moi vu que je ne dispose pas d'une carte ATI pour les v�rifier. Si je me trompe, n'h�sitez pas � me corriger, � m'insulter ou � m'envoyer votre carte ! 8-)
Les cartes ATI sont plus ou moins bien g�r�es par le pilote vesafb selon leur qualit� intrins�que. Heureusement, il existe un gestionnaire de m�moire vid�o sp�cifique aux cartes ATI. En supposant que vous employez menuconfig pour param�trer le noyau avant une compilation, ex�cutez les instructions suivantes
Allez dans le menu ``Code Maturity Level'' et activez l'option suivante :
Dans le menu ``Console Drivers'', s�lectionnez :
Recompilez votre noyau et modifiez le fichier /etc/lilo.conf.
Inspirez vous du mien, ce sera le plus rapide.
# Fichier de configuration de LILO boot = /dev/hda3 delay = 30 prompt vga = 792 # N�cessaire pour une r�initialisation dans un �tat normal # Linux bootable partition config begins image = /vmlinuz append = "video=atyfb:mode:1024x768,font:SUN12x22" root = /dev/hda3 label = Linux read-only # Non-UMSDOS filesystems should be mounted read-only for checking
La ligne ``atyfb:mode:1024x768,font:SUN12x22'' indique que le pilote op�rera dans une r�solution de 1024 par 768.
Vous devrez ensuite cr�er les p�riph�riques associ�s au gestionnaire de m�moire vid�o dans le r�pertoire /dev. Pour le premier, il vous suffit de taper :
# mknod /dev/fb0 c 29 0
# mknod /dev/fb1 c 29 32
# mknod /dev/fb7 c 29 224
video=atyfb:[option[,option[,option...]]]
o� vous disposez des options suivantes :
Voici une liste de cartes qui fonctionnent avec vesafb:
Une liste de cartes m�res incluant un jeu de composants graphiques :
Les cartes qui ne fonctionnent pas :
A ma connaissance, Vesafb ne peut pas �tre modularis�. Les d�veloppeurs de vesafb s'y atteleront peut-�tre un jour. De toute fa�on, si le pilote est modularis�, vous ne disposerez d'aucun affichage � l'�cran tant que le module vesafb n'aura pas �t� modprob�. Il vaut s�rement mieux le laisser dans le noyau, des fois que le d�marrage se passe mal.
[Tir� du fichier VGA-softcursor.txt - merci � Martin Mares!]
Linux offre une certaine latitude pour modifier l'allure du curseur. En principe, vous pouvez fixer la taille de celui-ci et, par la m�me occasion, contourner quelques probl�mes mat�riels de cartes Trident d�fectueuses (cf. #define TRIDENT_GLITCH dans le fichier drivers/char/vga.c). Si vous activez l'option de g�n�ration logicielle du curseur ("Software generated cursor"), des nouveaut�s se pr�sentent : un curseur rouge, un qui intervertisse la couleur de premier plan et celle du fond, une mise en relief du caract�re actif qui laisse le curseur mat�riel visible ou non. Je n'ai s�rement pas pens� � tout.
On contr�le l'allure du curseur via la s�quence d'�chappement
<ESC>[?1;2;3cou 1, 2 et 3 sont des param�tres que l'on va d�crire � pr�sent. Les param�tres absents prennent la valeur 0.
Le premier param�tre correspond � la taille du curseur (0=d�faut, 1=transparent, 2=soulign�, ..., 8=caract�re plein). Ajoutez 16 pour rendre actif le curseur logiciel, 32 si la couleur de fond doit �tre syst�matiquement chang�e, 64 pour que les couleurs de premier plan et de fond soient distinctes. La graisse est ignor�e pour les deux derniers attributs.
Le second param�tre indique quels sont les bits d'attributs � changer (un simple ou exclusif). Sur un �cran VGA standard, les quatre bits de poids fort pr�cisent le fond et les quatre de poids faible le premier plan. Dans chaque quartet, les trois bits de poids faible donnent la couleur et celui de poids fort active la mise en relief (ou active le clignotement suivant la configuration de la carte VGA).
Le troisi�me param�tre correspond aux valeurs que doivent prendre les bits que l'on souhaite modifier. Le positionnement d'un bit a lieu avant son masquage; on force donc � 0 un bit en l'activant � la fois dans le masque de s�lection et dans celui de positionnement.
Un curseur qui souligne et clignote : echo -e '\033[?2c' Un bloc qui clignote : echo -e '\033[?6c' Un bloc rouge qui ne clignote pas : echo -e '\033[?17;0;64c'
Cette partie d�crit les options offertes par le pilote de m�moire vid�o sur les machines Atari m68k.
Couleurs 320x200 320x480 640x200 640x400 640x480 896x608 1280x960 ---------+--------------------------------------------------------------- 1 bit | sthigh vga2 falh2 tthigh 2 bits | stmid vga4 4 bits | stlow ttmid/vga16 falh16 8 bits | ttlow vga256
ttlow, ttmid et tthigh sont seulement employ�s sur les mod�les TT tandis
que vga2, vga4, vga15, vga256, falh3 et falh16 ne servent que sur le
Falcon.
Lorsqu'une option video=xxx est donn�e au noyau, en l'absence toute
sous-option, le noyau teste les modes vid�o dans l'ordre suivant jusqu'� ce
qu'il en trouve un d'adapt� au mat�riel:
ttmidtthighvga16sthighstmidvideo=vga16 procure un �cran en 640 par 480 avec une
profondeur de 4 bits.
Options suppl�mentaires disponibles avec le param�tre video=xxx :
inverse - inversion des couleur de fond et de premier plan.
Normalement le fond est noir; cette option le rend blanc.font - fonte � employer en mode texte. Les fontes suivantes sont
actuellement disponibles : VGA8x8, VGA8x16, PEARL8x8.
La fonte VGA8x8 est utilis�e par d�faut si la dimension
verticale de l'�cran est inf�rieure � 400 pixels sans quoi la fonte
VGA8x16 est employ�e.internal - tr�s int�ressant. Se reporter � la section suivante. external - idem.monitorcap - description des modes multisync disponibles.
PROSCRIT pour les moniteurs � fr�quence fixe.Syntaxe : internal:(xres);(yres)[;(xres_max);(yres_max);(offset)]
L'option indique les fonctionnalit�s ajout�s par certains p�riph�riques
vid�o tels les modes d'OverScan. (xres) et (yres) fournissent
les dimensions �tendues de l'�cran.
Si vos modes d'OverScan n�cessitent une bordure noire, vous devrez
expliciter les trois derniers arguments de la sous-option internal:.
(xres_max) correspond � la plus grande dimension de ligne accept�e par
le mat�riel tandis que (yres_max) donne le nombre maximal de lignes et
(offset) le d�calage en octets entre la partie visible de la m�moire
vid�o et son emplacement physique.
Les mat�riel vid�o �tendu requiert souvent une activation qui fait appel aux
options "switches=*". [L'auteur appr�cierait de recevoir des informations
suppl�mentaires � ce sujet. La documentation m68k du noyau manque de clart�
sur ce sujet et l'auteur ne poss�de pas d'Atari! Des exemples seront �galement
les bienvenus.]
Syntaxe :
external:(xres);(yres);(depth);(org);(scrmem)[;(scrlen)[;(vgabase)[;(colw)[;(coltype)[;(xres_virtual)]]]]]
On rentre dans le compliqu�. Le pr�sent document essaye d'�tre aussi clair que possible mais l'auteur n'a rien contre une relecture afin d'�tre s�r qu'il n'a rien loos^H^Hup�.
Cette sous-option indique que vous disposez de p�riph�riques vid�o externes (vraisemblablement une carte vid�o) et indique comment Linux doit l'employer. Normalement, le noyau se limite � ce qu'il peut apprendre des p�riph�riques vid�o internes. Vous devez donc lui fournir tous les param�tres n�cessaires afin qu'il soit en mesure de g�rer des p�riph�riques externes. Il y a deux limitations : vous basculerez dans le mode ad�quat avant l'initialisation et une fois celle-ci effectu�e, vous ne pourrez pas changer de mode.
Les trois premiers param�tres sont �vidents. Ils correspondent aux dimensions de la zone d'affichage : hauteur et largeur en pixel suivies de la profondeur. Le param�tre de profondeur servant d'exposant au nombre 2 donne le nombre de couleurs. Par exemple, pour un affichage en 256 couleurs, vous pr�ciserez un param�tre de 8. Le param�tre d�pend de l'adaptateur graphique externe bien que vous soyez de toute fa�on limit� par le mat�riel.
Vous devez ensuite d�crire au noyau l'organisation de la m�moire vid�o via
le param�tre (org).
n - plans dispos�s normalement, les uns � la suite des autres.i - plans entrelac�s, c'est � dire 16 bits du premier plan, puis
du suivant etc. Seuls les modes vid�o natifs d'Atari utilisent �a et
aucune carte vid�o ne le g�re.p - pixels regroup�s. Les bits constitutifs des diff�rents plans
d'un m�me pixel se suivent. Ce mode est le plus courant en 256
couleurs.t - couleurs vraies. Il s'agit du mode pr�c�dent en l'absence de
toute table de correspondance des couleurs. Ces modes sont
g�n�ralement sur 24 bits et procurent quelques 16,8 millions de
couleurs.A cot� de �a, le param�tre (org) a une signification bien diff�rente
pour les modes monochromes.
n - couleurs usuelles, c'est � dire 0 pour le blanc et 1 pour le
noir;i - couleurs invers�es, c'est � dire 0 pour le noir et 1 pour le
blanc.L'�l�ment suivant ayant trait au p�riph�rique vid�o fixe l'adresse de base
de la m�moire vid�o. Il est donn� par le param�tre (scrmem) sous
forme hexad�cimal (pr�fix� par 0x). Vous devriez trouver cette
information dans la documentation fournie avec le p�riph�rique.
Le param�tre suivant, (scrlen), fournit au noyau la taille de la zone de
m�moire vid�o. S'il est absent, il est calcul� � partir des valeurs de
(xres), (yres) et (depth). En bref, il ne sert � rien de
pr�ciser une valeur. Si vous donnez � sa suite le param�tre (vgabase),
laissez le champ vide en rentrant deux point-virgules. Autrement, oubliez le.
Le param�tre (vgabase) est optionnel. En son absence, le noyau ne pourra
lire ni �crire le moindre des registres de couleur du p�riph�rique et il vous
faudra donc installer les couleurs appropri�es avant le d�marrage de Linux.
Si la carte est compatible VGA, vous pouvez donner au noyau l'adresse o� se
trouvent les registres vid�o de fa�on � ce qu'il modifie lui-m�me les tables
des couleurs. Vous trouverez cette information dans la documentation fournie
avec le p�riph�rique. Afin d'�tre clair, (vgabase) est une adresse
de base, donc align�e sur un multiple de 4k. Pour l'acc�s en lecture ou
en �criture aux registres, le noyau utilise une plage d'adresses comprises
entre (vgabase) + 0x3c7 et (vgabase) + 0x3c9. La valeur est donn�e
en hexad�cimal et doit �tre pr�fix�e par 0x (tout comme (scrmem)).
(colw) ne sert que si (vgabase) est sp�cifi�. Il donne au
noyau la taille des registres de couleur, c'est � dire le nombre de bits
par couleur (rouge/verte/bleue). La valeur par d�faut est de 6 bits mais
il est courant d'en sp�cifier 8.
(coltype) s'emploie en conjonction avec (vgabase). Il pr�cise
aux noyau le type des registres de la carte graphique. Actuellement, deux
mod�les sont g�r�s : vga et mv300. Par d�faut, vga est
employ�.
(xres_virtual) n'est n�cessaire qu'avec les cartes ProMST/ET4000 pour
lesquelles la longueur physique des lignes diff�re de leur taille visible.
Avec une ProMST, on donnera la valeur 2048 tandis que pour l'ET4000 cela
d�pendra de l'initialisation de la carte vid�o.
Cette partie d�crit les options offertes sur les Amiga, options voisines de celles de l'Atari m68k.
�a d�pend du composant employ� dans votre Amiga. Il y en a essentiellement
trois : OCS, ECS et AGA. Tous on recours au pilote de m�moire vid�o.
ntsc - 640x200ntsc-lace - 640x400 pal - 640x256 pal-lace - 640x512multiscan - 640x480multiscan-lace - 640x960euro36 - 640x200euro36-lace - 640x400euro72 - 640x400euro72-lace - 640x800super72 - 800x300super72-lace - 800x600dblntsc - 640x200dblpal - 640x256dblntsc-ff - 640x400dblntsc-lace - 640x800dblpal-ff - 640x512dblpal-lace - 640x1024vga - 640x480vga70 - 640x400Elles sont voisines de celles de l'Atari m68k :
depth - pr�cise le nombre de bits par pixel.inverse - m�me chose que sur les Atari.font - m�me chose que sur les Atari, mais la fonte PEARL8x8
remplace la fonte VGA8x8 si la largeur de la zone d'affichage est
inf�rieure � 400 pixels.monitorcap - description des modes multisync disponibles. PROSCRIT
pour les moniteurs � fr�quence fixe.
Phase5 CyberVision 64 (composant S3 Trio64)Phase5 CyverVision 64-3D (composant S3 ViRGE)MacroSystems RetinaZ3 (composant NCR 77C32BLT)Helfrich Piccolo, SD64, GVP ECS Spectrum, Village Tronic Picasso
IIII+ and IV/ (Cirrus Logic GD542x/543x)La version courante du gestionnaire de m�moire vid�o ne g�re que les modes choisis sous MacOS avant l'initialisation de Linux ainsi que les modes couleur en 1, 2, 4 et 8 bits.
Le pilote g�re les options de la forme :
video=macfb:<font>:<inverse>Les fontes VGA8x8, VGA8x16, 6x11, etc... sont disponibles. L'option inverse permet bien s�r d'inverser la vid�o.
L'auteur aimerait recevoir des informations relatives au gestionnaire de m�moire vid�o sur ces machines.
Pour l'instant il n'y a que la carte PCI TGA. Elle offre un mode de 80 lignes par 30 colonnes en 640x480 avec une profondeur de 8, 24 ou 32 bits.
La carte graphique suivante a �t� test�e avec succ�s :
DEC TGA PCI (DEC21030) - 640x480 @ 8 bit or 24/32 bit versions
Une option de la PROM permet l'envoi des caract�res d'affichage � l'�cran ou sur une console s�rie. Jetez un oeil � la FAQ du Frame Buffer sur Sparc : http://c3-a.snvl1.sfba.home.com/Framebuffer.html>.
Pendant la configuration du noyau (make config ou autre), il vous faut
choisir entre promcon ou fbcon. La compilation des deux est possible
mais il faudra sp�cifier au noyau le pilote � employer. Par d�faut, fbcon
est essay� en premier au d�marrage. Si promcon n'a pas �t� s�lectionn�,
dummycon est activ� pendant l'initialisation. Une fois les bus
initialis�s, si fbcon est compil�, le noyau recherche les p�riph�riques
pr�c�dents et se sert de fbcon. En l'absence de gestionnaires de m�moire
vid�o, le noyau a recours � promcon.
Voici les options du noyau :
video=sbus:options
options inclue les �l�ments suivants, s�par�s par une virgule :
nomargins marge nulle;
margins=12x24 marge de 12 par 24 (calcul� par d�faut en
fonction de la r�solution);
off inhibition de la d�tection des pilotes de
m�moire vid�o SBus/UPA;
font=SUN12x22 emploi d'une fonte particuli�re.
Au d�marrage, un param�trage de la forme
video=sbus:nomargins,font=SUN12x22procure une agr�able console en mode texte, rapide, avec une r�solution de 96 par 40 qui ressemble � une console Solaris avec la couleur et les terminaux virtuels en plus comme sur les compatibles PC.
Pour que l'affichage se fasse avec la fonte SUN12x22, vous devez l'activer
durant la configuration du noyau (d�sactivez l'option fontwidth != 8).
Le pilote de m�moire vid�o acc�l�r� g�re n'importe quelle fonte dont la largeur
est comprise entre 1 et 16 pixels tandis que le pilote de base ne g�re que les
fontes larges de 4, 8, 12 ou 16 pixels.
Un paquetage r�cent des consoletools est recommand�.
Il n'est pas besoin de modifier quoi que ce soit avec ce type de machines. Tout est g�r� automatiquement. En particulier, les Indys sont c�bl�s de fa�on � offrir une console 160x64. Une r��criture du code de gestion de la console pour les Indys �tant en cours, on gardera un oeil sur cette section.
Pour les Netwinders (qui reposent sur le processeur RISC ARM SA110 au charme si d�licieusement british), il existe deux versions du gestionnaire de m�moire vid�o pour les Cyber2000 : un pour les noyaux 2.0.x, l'autre pour les 2.2.y. Tant l'activation que l'emploi du pilote sont assez naturels avec les deux branches du noyau. N�anmoins, en 2.0.x, la r�solution et la profondeur sont cod�es en dur (beuh...). Heureusement, la version 2.2.x est plus souple, du moins le sera une fois les pilotes davantage stabilis�s. Le mieux que vous puissiez faire afin que tout fonctionne reste encore de lire la documentation fournie avec la portion ARM des sources du noyau. Les Netwinders int�grent un composant VGA mais il ne s'est malheureusement jusqu'ici trouv� personne pour porter vgafb. [Je m'y attelerai si quelqu'un me fournissait un Netwinder avec lequel jouer]
Les Acorns offrent un pilote de m�moire vid�o depuis les temps anciens des noyaux 1.9.x. Cependant, le gestionnaire Acornfb des noyaux 2.2.x est compl�tement nouveau puisque l'interface d'acc�s � la m�moire vid�o a �t� modifi�e au cours du d�veloppement des noyaux 2.1.x (qui devinrent naturellement les 2.2.x). Comme pr�c�demment, il n'est gu�re difficile d'activer le pilote et de configurer la profondeur et la r�solution.
A ma surprise, m�me le Psion 5 et le Geofox disposent d'un pilote de m�moire vid�o ! On m'a dit que le manchot passait d'ailleurs plut�t bien. S'il vous pla�t, donnez moi un Psion 5 !
Cette partie du document a �t� fournie gracieusement par Frederick A. Niles qui conserve tous ses droits sur les informations donn�es.
Les quelques pages qui suivent sont cens�es permettre une premi�re prise en main des configurations � deux �crans sous Linux. Bien que le processus se d�roule naturellement, les occasions de se tromper ne manquent pas.
Je me suis focalis� sur la mise en place d'un serveur X sur un second moniteur. L'int�r�t en est que l'on croise de temps � autre des personnes se d�barrassant de vieux moniteurs de 19 ou 20 pouces � fr�quence fixe car ils ne peuvent plus s'en servir. On peut ainsi d�marrer avec un petit moniteur multisync et disposer de X sur un moniteur de grandes dimensions.
Comme il s'agit d'un domaine en plein d�veloppement, l'information �volue rapidement. Le contenu de ce document pourrait tr�s bien �tre d�pass�, voire compl�tement faux, lorsque vous le lirez.
** ATTENTION ** Ce texte a �t� r�dig� avant la sortie de la version 4.0 de la XFree86 qui devrait modifier pas mal de choses. Essayez d'obtenir une nouvelle version de ce document si elle existe.
Le retour de la part des utilisateurs sera plus que certainement le bienvenu. Sans vos remarques et vos questions, ce document n'existerait pas. N'h�sitez donc pas � me contacter � l'adresse suivante : Frederick.A.Niles@gsfc.nasa.gov.
Les personnes suivantes ont particip� � l'�laboration de ce Mini-HOWTO :
vandrove@vc.cvut.czehliar@lysator.liu.se (x2x)m.bizzarri@icube.it (multiple X servers)L'auteur de ce document d�gage toute responsabilit� quant � son contenu. Vous employez les notions, exemples et tout ce qui figure ici � vos risques et p�rils. S'agissant d'une nouvelle version de ce document, des informations erron�es ou inad�quates peuvent tr�s bien entra�ner la d�gradation de votre mat�riel. Fa�tes-y attention et, bien que ce soit hautement improbable, je me d�charge de toute responsabilit� � cet �gard.
Copyright (c) 1999 Frederick Niles
La distribution de ce document doit se conformer aux termes de la licence LDP tels que d�finis � l'adresse : sunsite.unc.edu/LDP/COPYRIGHT.html>.
La plupart des cartes vid�os supposent qu'elles assument seules cette fonction au sein du syst�me. Elles occupent donc en permanence l'espace d'adressage de l'adaptateur graphique primaire. Il existe quelques exceptions :
Ce Mini-HOWTO traite avant tout de logiciel libre. Certains serveurs X commerciaux sont n�anmoins capables de g�rer plusieurs moniteurs tels le serveur Metro-X de Metro Link (www.metrolink.com) et Accelerated-X de Xi Graphics (www.xig.com).
Les patches et programmes suivants sont n�cessaires :
Commencez par patcher votre version du noyau avec le patche "fbaddon". Ensuite, vous configurerez le noyau et activerez la gestion de la m�moire vid�o. Si vous disposez de cartes Matrox, incluez le pilote d'acc�l�ration unifi� Matrox. Excluez le gestionnaire de m�moire vid�o VESA. Activez bien s�r la gestion de plusieurs adaptateurs, recompilez le noyau et r�initialisez le syst�me.
A pr�sent, installez l'utilitaire "fbset" et lisez attentivement la documentation relative � son param�trage. La mise en place d'un fichier "/etc/fb.modes" est vivement recommand� une fois que vous vous serez d�cid� sur une configuration. Le paquetage fbset comprend un script Perl de conversion du fichier XF86Config en param�tres pour fb.modes. Vous trouverez mon script en shell Bourne dans les annexes A et B.
Vous devez vous mettre au point sur l'emploi du pilote de m�moire vid�o avec un seul adaptateur et bien identifier tout ce qui n'a rien � voir avec la gestion de plusieurs. Vous vous �pargnerez ainsi pas mal de noeuds au cerveau. Je me focalise surtout sur la mise en place de X au niveau du second moniteur vu que la plupart des autres op�rations de configuration en forment un sous-ensemble.
Compilez le programme "con2fb". Lanc� sans arguments, il fournit le message suivant : "usage: con2fb fbdev console". Une commande telle que "con2fb /dev/fb1 /dev/tty6" attacherait la console virtuelle num�ro 6 au second gestionnaire de m�moire vid�o. Ctrl-Alt-F6 vous basculera dans cette console qui s'affichera sur le second moniteur.
La mise en place des param�tres "fbset" doit se cantonner au moniteur avec lequel "fbset" est employ�. Fa�tes donc attention � bien employer l'option "-fb" avec le second moniteur. Plus pr�cis�ment, si vous ne voulez rien faire d'autre qu'accorder la r�solution verticale virtuelle avec la r�solution verticale r�elle : "fbset -fb /dev/fb1 -vyres 600" (par exemple). L'affichage en mode texte en est s�rieusement ralenti mais sans cela X reste vraiment hideux.
Le fichier framebuffer.txt explique bien mieux que je ne puis le faire mais voici les deux points essentiels :
# Serveur X s'appuyant sur le gestionnaire de m�moire vid�o.
Section "Screen"
Driver "fbdev"
Device "Millennium"
Monitor "NEC MultiSync 5FGp"
Subsection "Display"
Depth 8
Modes "default"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 16
Modes "default"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 24
Modes "default"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 32
Modes "default"
ViewPort 0 0
EndSubsection
EndSection
Restreignez vous aux modes "default" car je ne pense pas qu'il y en ait d'autres qui fonctionnent avec le pilote de m�moire vid�o Matrox.
Positionnez la variable d'environnement FRAMEBUFFER sur le second p�riph�rique de m�moire vid�o : "export FRAMEBUFFER=/dev/fb1" ou : "setenv FRAMEBUFFER /dev/fb1" X doit �tre lanc� avec des param�tres lui sp�cifiant � la fois la profondeur souhait�e au niveau des couleurs et un num�ro correspondant � la console virtuelle employ�e. Par exemple : "startx -- :0 -bpp 16 vt06". Le serveur X en 16 bits par pixel d'identifiant ":0" est attach� � la console virtuelle num�ro 6. Utilisez ":1" au lancement d'un autre serveur X en le liant � une console d�pendant de l'autre gestionnaire de m�moire vid�o et vous disposerez de deux serveurs X fonctionnant simultan�ment.
Les �tapes de mise en place d'un serveur X sur un second moniteur peuvent �tre ainsi r�sum�es :
alias startxfb = " setenv FRAMEBUFFER /dev/fb\!*; # l'argument passe a l'alias est recupere con2fb $FRAMEBUFFER /dev/$tty; # positionne le pilote sur la console courante fbset -fb $FRAMEBUFFER 1280x1024@62; # Cf /etc/fb.modes startx -- :\!* -bpp 16 vt0`echo $tty | cut -dy f 2`' # execution de X "
Ces lignes correspondent au contenu de mon .cshrc aux commentaires pr�s mais ils aident, avec les sauts de ligne, � en faciliter la lecture. Je fournis le num�ro du pilote de m�moire vid�o comme argument � l'alias.
Si quelqu'un me fournit un �quivalent pour bash, je l'incluerai ici. La commande tty vous fournira le nom de la console courante.
Je n'ai pas encore trouv� comment passer au niveau 5 dans une configuration � deux adaptateurs avec un serveur sur le second moniteur ou sur les deux. Bien que l'ajout d'une ligne au fichier Xservers de xdm/gdm soit ais�, la contrainte de d�marrer le serveur X depuis la console g�r�e par le pilote de m�moire vid�o interdit cette solution. Si quelqu'un a une id�e, qu'il m'en fasse part afin que je puisse l'ajouter.
x2x vous permet de passer d'un serveur X � l'autre lorsque vous atteignez le bord d'un �cran. Aux derni�res nouvelles, ce programme se trouvait � l'adresse suivante : http://ftp.digital.com/pub/DEC/SRC/x2x/>. La distribution Debian en propose un paquetage. Je n'ai pas eu l'occasion de l'essayer mais plusieurs utilisateurs ont fait part d'exp�riences r�ussies.
Il est bon de garder pr�sente � l'esprit l'existence de certaines commandes quand on dispose de plusieurs adaptateurs (surtout quand on �crit des scripts). * "chvt" permet de passer d'une console virtuelle (VT) � une autre. * "openvt" ex�cute un programme dans une console diff�rente. * "tty" renvoie le nom de la console courante.
Notez le positionnement de bpp.
#!/usr/bin/octave -q
bpp = 16;
DCF = sscanf(argv(1,:), "%f");
HR = sscanf(argv(2,:), "%f");
SH1 = sscanf(argv(3,:), "%f");
SH2 = sscanf(argv(4,:), "%f");
HFL = sscanf(argv(5,:), "%f");
VR = sscanf(argv(6,:), "%f");
SV1 = sscanf(argv(7,:), "%f");
SV2 = sscanf(argv(8,:), "%f");
VFL = sscanf(argv(9,:), "%f");
pixclock = 1000000 / DCF;
left_margin = HFL - SH2;
right_margin = SH1 - HR;
hsync_len = SH2 - SH1;
# 3) vertical timings:
upper_margin = VFL - SV2;
lower_margin = SV1 - VR;
vsync_len = SV2 - SV1;
RR = DCF / (HFL * VFL) *1e6;
HSF = DCF / HFL * 1e3;
printf("mode \"%dx%d\"\n",HR,VR);
printf(" # D: %3.2f MHz, H: %3.2f kHz, V: %2.2f Hz\n", DCF, HSF, RR);
printf(" geometry %d %d %d %d %d\n", HR, VR, HR, VR, bpp);
printf(" timings %d %d %d %d %d %d %d\n", ...
pixclock, left_margin, right_margin, ...
upper_margin, lower_margin, ...
hsync_len, vsync_len);
printf("endmode\n");
Le script Octave "cvtmode" est utilis�.
#!/bin/sh # Shell script to convert XF86Config file to fb.modes file. # Uses octave script cvtmode.m if [ -z $1 ]; then FILE=/etc/X11/XF86Config else FILE=$1 fi i=1 LEN=`grep Modeline $FILE | wc -l` while expr $i \< $LEN > /dev/null ; do CURLINE=`grep Modeline $FILE | cut -d'"' -f 3-20 | head -$i | tail -1 ` ./cvtmode.m $CURLINE echo " " i=`expr $i + 1` done
Afin de pouvoir modifier les fontes, vous devez installer kbd-0.99. Le logiciel est disponible via ftp://ftp.win.tue.nl/pub/linux/utils/kbd>.
Le t�l�-chargement et l'installation de kbd-0.99 r�side en ce que vous pourrez charger les fontes internationales (dont l'Euro) dans votre console. Je trouve tr�s chic *en fran�ais dans le texte* d'avoir trois symboles sur mon clavier : le dollar, la livre et l'Euro.
Pour changer de mode (640x480, 800x800, etc ...), vous avez besoin de fbset (fbset-19990118.tar.gz pour l'instant) : http://www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz> Le logiciel est fourni avec une documentation compl�te sur son emploi.
Si votre version de XFree86 est ant�rieure � la 3.3.3.1, il est urgent de proc�der � une mise � jour. Cette version comprend le pilote FBDev X pour les gestionnaires de m�moire vid�o. Autrement, vous pouvez compiler votre propre pilote FBDev pour des versions de XFree telles la 3.3.2 ou la 3.3.3.
Allez sur http://www.xfree86.org> et t�l�-chargez les derni�res sources du serveur X. [NdT : le recours � un miroir ou � ftp://ftp.lip6.fr/pub/X11> sera peut-�tre plus rapide]
Recompilez le pilote. Ne vous souciez pas des r�f�rences ayant trait � m68k : les architectures Intel sont support�es. Recompilez le tout. �a va prendre un moment compte tenu de la taille des sources.
Si vous manquez de temps, les sites suivants proposent des versions pr�-compil�es. Notez que ces sites n'ont rien d'officiel et que vous utiliserez leurs binaires � vos risques et p�rils.
Pour une version libc5 : http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.gz>. Pour une version glibc2 : http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.libc6.gz>, http://pobox.com/~brion/linux/fbxserver.html>.
On signale qu'X11 ne fonctionne pas avec certaines cartes graphiques lorsque le gestionnaire vesafb est actif. Si vous �tes dans ce cas, essayez le nouveau pilote XF86_FBdev pour X11.
Utilis� conjointement � vesafb, ce pilote peut permettre l'emploi de X11 � des r�solutions autrement inaccessibles au pilote X11 usuel (cartes MGA G200 par exemple).
XF86_FBdev requiert la configuration suivante du XF86Config :
Section "Screen"
Driver "FBDev"
Device "Primary Card"
Monitor "Primary Monitor"
SubSection "Display"
Modes "default"
EndSubSection
EndSection
Vous devrez �galement positionner XkbDisable dans la section Keyboard ou bien ex�cuter XF86_FBDev avec l'option '-kb' afin de g�rer correctement votre clavier. Sans XkbDisable, il vous faudra inclure les lignes suivantes dans votre .Xmodmap pour pr�ciser les effets des touches. Le m�me r�sultat s'obtient en �ditant son xkb si on le d�sire. XFree86 3.3.3.1 ne pr�sente plus ce d�faut. Il est donc vivement conseill� d'effectuer une mise � jour vers cette version qui de plus corrige d'autres bugs et inclut FBDev parmi les serveurs.
! Keycode settings required keycode 104 = KP_Enter keycode 105 = Control_R keycode 106 = KP_Divide keycode 108 = Alt_R Meta_R keycode 110 = Home keycode 111 = Up keycode 112 = Prior keycode 113 = Left keycode 114 = Right keycode 115 = End keycode 116 = Down keycode 117 = Next keycode 118 = Insert keycode 119 = Delete
Certaines adaptations seront s�rement n�cessaires (copier les codes du gestionnaire X11 utilis� et positionner le nom du pilote sur FBDev) mais c'est en substance ce qu'il vous faudra faire pour que le pilote vesafb de X11 fonctionne. Les probl�mes li�s � X11 devraient �tre r�solus dans les prochaines versions en ce qui concerne les cartes vid�o support�es.
Rien n'est plus simple si XFree86 (X11) est install� sur votre machine et que vous pouvez vous en servir normalement.
Le pilote de m�moire vid�o requiert les champs suivants :
Une ligne "Modeline: XFree86 comprend les champs suivants :
Modeline "1280x1024" DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
Quelques calculs sont n�cessaires pour la conversion. A titre d'exemple voici la conversion de valeurs extraites de mon XF86Config.
Modeline "1280x1024" 110.00 1280 1328 1512 1712 1024 1025 1028 1054
Tout d'abord le param�tre pixclock. XFree86 l'exprime en MHz et le pilote de m�moire vid�o en picosecondes (pourquoi? myst�re). On divise donc un million par DCF soit : 1,000,000 / 110.0 = 9090.9091
Pour les dur�es horizontales :
Soit, dans notre exemple :
Enfin les dur�es verticales :
Soit :
Les valeurs obtenues sont pass�es au gestionnaire de m�moire vid�o. Dans le cas du pilote matroxfb :
video=matrox:xres:<>,yres:<>,depth:<>,left:<>,right:<>,hslen:<>,upper:<>,lower:<>,vslen:<>
J'ai donc ins�r� la ligne suivante dans mon /etc/lilo.conf :
append = "video=matrox:xres:1280,yres:1024,depth:32,left:200,right:48,hslen:184,upper:26,lower:0,vslen:3"
Notez que le pixclock n'est pas employ� ici. Il n'est n�cessaire que si celui par d�faut ne vous convient pas. Il se fixe de la m�me fa�on ainsi qu'il a �t� auparavant expliqu� dans ce document.
Le logo se modifie par l'interm�diaire du fichier linux_logo.h dans le r�pertoire include/linux. Il s'agit d'un fichier d'en-t�te C peu �vident � manipuler, cependant il existe un module Gimp sp�cifique: http://registry.gimp.org/detailview.phtml?plugin=Linux+Logo>. Il suffit de disposer d'une image 80x80 comprenant au plus 224 couleurs. On peut laisser le module cr�er les trois variantes (2,16,224) ou on les cr�e soi-m�me et on les travaille avec le module. Le module r�clame un r�pertoire o� stocker le fichier. On sp�cifie ($SRCDIR)/include/linux/linux_logo.h et une fois la retouche d'image termin�e, il ne reste plus qu'� recompiler et r�installer le noyau. Si le noyau g�re le tampon de m�moire vid�o, le logo apparait au prochain red�marrage.
Que ceux qui sont int�ress�s aillent faire un tour du cot� de http://www.linux-fbdev.org> pour des informations relatives � la programmation du pilote.
La traduction originale de ce document en fran�ais se trouve � l'adresse suivante : http://www.freenix.org/unix/linux/HOWTO/>.