en fait, peu importe le mode (je suis perdu dans ces fb,fbdev,fbdev2,
directfb,vesafb,radeonfb, et cie ...) ...
fb : frame buffer : c'est la partie de la mémoire qui est écrit sur l'écran.
Grosso modo ton écran en 1024x768@32bits c'est uen image de type bitmap. Cette bitmap se trouve physiquement dans ta carte graphique dans une zone mémoire qui s'apelle le frame buffer.
Bien entendu la taille du framebuffer varie en fonction de la tailel de l'écran et de la profondeur de couleur.
bb : back buffer : c'est une autre zone mémoire disponible sur la carte graphique de même taille que le frame buffer. L'avantage du back buffer est qu'il peut être permuté très rapidement avec el frame buffer. Donc on affiche le frame buffer, on dessine dans le back buffer en prenant son temps et on inverse les deux buffers. Ainis le back buffer devient le frame buffer et est présenté à l'écran une fois "fini". Il peut y avoir plusieurs back buffer pour un frame buffer.
fbdev : c'est un device qui mappe le frame buffer de la carte graphique. Grosso-modo cat "mon bitmap" > /dev/fbdev affiche la bitmap à l'écran (pour peu que l'on soit en mode frame buffer et que la bitmap ait la bonne résolution)
fbdev2 : le même en mieux, maintenant on peut faire echo "ma résolution" > /dev/fbdev2 avant de faire le cat "mon bitmap" > /dev/fbdev2. Ca permet entre autre de mettre le frame buffer à la taille de l'image avant d'afficher l'image. Ca peut aussi permettre de faire faire de la fumée noire a des écrans un peu ancien.
directfb : permet à un flux de données d'aller s'inscrire directement dans le frame buffer via un meccanisme de DMA ou autre. En d'autres termes en directFB le logiciel dialogue écrit et lit directement sur la mémoire frame buffer de la carte graphique.
vesaFB : comem toutes les cartes graphiques ont un frame buffer différent (adressage mémoire variables, ordre des bits, zone d'init ici ou là) une norme a été créée pour simplifier la vie des dévellopeurs. Grosso modo on envoit la résolution suivit de la profondeur de couleru suivit du bitmap et le driver vesa s'occupe d'écrire tout ça dans le bon ordre pour que la carte graphique comprenne ce qu'on lui dit. Vesa est une norme et à peu près toutes les cartes graphiques la supportent. Dasn le pire des cas c'est logiciellement qu'il faut remettre les choses dans l'ordre.
RadeonFB : un directFB avec en plus gestion des back-buffers.
comment faire pour lancer une console en vesafb ?
En activant les options dans le kernel.
y a un truc ?
Non en fait c'est un manchot et c'est normal, si il apparait c'est que tu es en vesaFB.
si c'est le cas, je vais me jeter sur LIRC ...
Avant de t'arracher les cheveux apr poignées, si ta télécommande est reconnue par Mandrake comme une extension du clavier, il risque peut-être de falloir déchargé ce module. A voir avec des pros Mandrake pour savoir si c'est traité comme un device à part ou comme une extension. Mais si c'est uen extension c'est pas bon.
c pas en sortie, c en entrée ... au retour de l'hibernation ...
Oui donc en sortie du mode S4.
et tout ça, que ce soit avec le driver ATI officiel (3.12) ou le module "radeon" d'xorg ...
C'est malheureusement probablement le driver du kernel qui fait des siennes au niveau de la réinit de la carte graphique. Les modules XFree/Xorg n'y sont probablement pas pour grand chose. Mais là je en sais pas comment te dire autre chose que d'essayer toutes les possibilités. Vérifie bien que tout est compilé en module dans le kernel (DRI+AGP+RADEON) et met à jour. Bonne chance.
[^] # Re: Non tu n'es pas seul
Posté par Jerome Herman . En réponse au journal 2em journal de linuxien. Évalué à 6.
directfb,vesafb,radeonfb, et cie ...) ...
fb : frame buffer : c'est la partie de la mémoire qui est écrit sur l'écran.
Grosso modo ton écran en 1024x768@32bits c'est uen image de type bitmap. Cette bitmap se trouve physiquement dans ta carte graphique dans une zone mémoire qui s'apelle le frame buffer.
Bien entendu la taille du framebuffer varie en fonction de la tailel de l'écran et de la profondeur de couleur.
bb : back buffer : c'est une autre zone mémoire disponible sur la carte graphique de même taille que le frame buffer. L'avantage du back buffer est qu'il peut être permuté très rapidement avec el frame buffer. Donc on affiche le frame buffer, on dessine dans le back buffer en prenant son temps et on inverse les deux buffers. Ainis le back buffer devient le frame buffer et est présenté à l'écran une fois "fini". Il peut y avoir plusieurs back buffer pour un frame buffer.
fbdev : c'est un device qui mappe le frame buffer de la carte graphique. Grosso-modo cat "mon bitmap" > /dev/fbdev affiche la bitmap à l'écran (pour peu que l'on soit en mode frame buffer et que la bitmap ait la bonne résolution)
fbdev2 : le même en mieux, maintenant on peut faire echo "ma résolution" > /dev/fbdev2 avant de faire le cat "mon bitmap" > /dev/fbdev2. Ca permet entre autre de mettre le frame buffer à la taille de l'image avant d'afficher l'image. Ca peut aussi permettre de faire faire de la fumée noire a des écrans un peu ancien.
directfb : permet à un flux de données d'aller s'inscrire directement dans le frame buffer via un meccanisme de DMA ou autre. En d'autres termes en directFB le logiciel dialogue écrit et lit directement sur la mémoire frame buffer de la carte graphique.
vesaFB : comem toutes les cartes graphiques ont un frame buffer différent (adressage mémoire variables, ordre des bits, zone d'init ici ou là) une norme a été créée pour simplifier la vie des dévellopeurs. Grosso modo on envoit la résolution suivit de la profondeur de couleru suivit du bitmap et le driver vesa s'occupe d'écrire tout ça dans le bon ordre pour que la carte graphique comprenne ce qu'on lui dit. Vesa est une norme et à peu près toutes les cartes graphiques la supportent. Dasn le pire des cas c'est logiciellement qu'il faut remettre les choses dans l'ordre.
RadeonFB : un directFB avec en plus gestion des back-buffers.
comment faire pour lancer une console en vesafb ?
En activant les options dans le kernel.
y a un truc ?
Non en fait c'est un manchot et c'est normal, si il apparait c'est que tu es en vesaFB.
si c'est le cas, je vais me jeter sur LIRC ...
Avant de t'arracher les cheveux apr poignées, si ta télécommande est reconnue par Mandrake comme une extension du clavier, il risque peut-être de falloir déchargé ce module. A voir avec des pros Mandrake pour savoir si c'est traité comme un device à part ou comme une extension. Mais si c'est uen extension c'est pas bon.
c pas en sortie, c en entrée ... au retour de l'hibernation ...
Oui donc en sortie du mode S4.
et tout ça, que ce soit avec le driver ATI officiel (3.12) ou le module "radeon" d'xorg ...
C'est malheureusement probablement le driver du kernel qui fait des siennes au niveau de la réinit de la carte graphique. Les modules XFree/Xorg n'y sont probablement pas pour grand chose. Mais là je en sais pas comment te dire autre chose que d'essayer toutes les possibilités. Vérifie bien que tout est compilé en module dans le kernel (DRI+AGP+RADEON) et met à jour. Bonne chance.