Accès au buffer video sous Linux, en console - Page 1

yop,


Je voudrais savoir comment accéder au buffer video d'un kernel Linux, éventuellement quand X est lancé, mais surtout, sans X, en console.
En fait, je voudrais pouvoir lire ce buffer, et enregistrer l'image qui s'y trouve, ou y afficher quelque chose. Comme si j'accédais sur TI aux ports qui donnent la dimension et l'adresse de l'écran, et qu'ensuite j'allais lire ce qui se passe à $4C00.

Mais quand je vois des trucs comme ça : http://en.wikipedia.org/wiki/Video_memory j'ai peur. Ca a l'air complexe, avec plusieurs couches d'abstraction différentes.
Mon but est de récupérer :
- les dimensions (Lxh) et le nombre de couleurs de l'écran
- l'adresse de l'écran, ou du moins les appels système permettant de lire/écrire à l'écran.
Le tout, indépendamment du driver utilisé (j'ai l'impression qu'un kernel Linux boote en vesa, puis, dans mon cas, charge Nouveau). Je veux m'adresser au kernel directement, pour être indépendant du driver chargé.

J'ai commencé à regarder dans kernel-headers, mais c'est vaste ce paquet, je ne sais pas si c'est vers là qu'il faut chercher. Et j'ai jamais mis les doigts dans ce système, les sources sont quand même "légèrement" plus grosses que celles de PedroM, donc c'est "un peu" plus chaud de trouver une direction dans laquelle aller quand on ne connait pas. Toute aide sera la bienvenue, merci d'avance.

Ah, j'ai déjà fait ça il y a quelques années, mais c'était sans serveur X (le but était d'éviter de devoir installer un serveur X justement, sur une config légère). Je vais te retrouver les documents qui parlaient de tout ça

Zerosquare (./2) :
mais c'était sans serveur X

Parfait ! Sous X, je m'en fous, et c'est sûrement faisable à plus haut niveau. Merci d'avance !!

Ah oui mais je pense à un truc : toi tu es déjà en mode graphique et il y a déjà un driver qui le gère, c'est ça ? Donc pour l'accès hardware il risque d'avoir un conflit, il y a probablement une API qui est mieux adaptée pour ça.

Dans mon cas Linux bootait en mode texte, et c'était mon prog qui s'occupait de switcher en mode graphique et de gérer tout le reste.

Linux passe en mode graphique aprèsa voir chargé Nouveau, le driver.

Je ne sais pas comment ça marche, d'après ce que tu dis, il y a un mode texte (lignes * colonnes) où la l'écran est en fait une "matrice de texte" ? Et un mode graphique où c'est un tableau de pixels ?
Et en mode texte, le kernel ne donne pas moyen d'accéder aux pixels pour lire le contenu de l'écran pixel par pixel ?

Je comprends pas le fonctionnement, justement toute doc précise à ce sujet est la bienvenue. Et des docs, google m'en donne, mais je suis pas encore tombé sur ces explications-là.

Folco (./5) :
Je ne sais pas comment ça marche, d'après ce que tu dis, il y a un mode texte (lignes * colonnes) où la l'écran est en fait une "matrice de texte" ? Et un mode graphique où c'est un tableau de pixels ?

Oui, ça fonctionne comme ça.

Folco (./5) :
Et en mode texte, le kernel ne donne pas moyen d'accéder aux pixels pour lire le contenu de l'écran pixel par pixel ?

Non, en mode texte, tu ne peux accéder que caractère par caractère (même si tu peux redéfinir le bitmap associé à chaque caractère ASCII).

Mais si tu as par exemple un logo (genre Tux ou un autre), c'est que tu es en fait en mode graphique et que Linux émule une console texte. C'est le cas de la majorité des distribs actuelles je pense. C'est apparement géré par Bootsplash.

Ok. Donc dans mon cas, je peux parler d'image, vu que j'ai un mode graphique émulant un mode console grâce à nouveau.
La question est donc :
- comment accéder à ce buffer ?
- l'accès fourni et-il dépendant (plus ou moins fortement) du pilote graphique ?

Sachant que mon but est d'écrire un programme indépendant du driver graphique chargé, la seconde question me fait peur. Tous les paquets de X (nv, vesa, ati, nouveau etc) sont-ils des interfaces vers les différents drivers pour créer une couche entre les fonctions de plus haut niveau de X et les drivers, ou alors est-ce que ce sont les drivers à proprement parler, fournis par X, et fournissant tous une interface standard pour être lus ou écrits ?

Là ça dépasse mes connaissances...

!call pmandin
--- Call : pmandin appelé(e) sur ce topic ...

Tu as de la chance, on a l'un des dévs de Nouveau sur yN ^^

\o/ Merci

T'es pas censé accéder à l'écran hein. Tu fais un programme X donc tu utilises une fenêtre comme tout le monde (et là tu peux avoir accès à son contenu au pixel). Tu dois pouvoir faire du plein écran aussi mais ça je n'ai aucune idée de comment ça marche.
Dans tous les cas sois content d'avoir un serveur graphique plutôt que vouloir le bypasser, parce que gérer la souris et le clavier... c'est la meurde...

Tu connais pas Folco, toi
(plus sérieusement il a dit qu'il voulait que son programme fonctionne même sans serveur X, donc je suppose qu'il a une bonne raison)

Sisi je vois où il veut en venir, mais je crains que ça va être un truc trop gros parce qu'il veut tout maîtriser, et il ne pourra pas faire beaucoup plus évolué que ce qu'il faisait sur TI. Pour ça que je préfère le mettre en garde c'est tout ^^
[edit] pas vu ta parenthèse.

Folco > Regarde du côté de http://en.wikipedia.org/wiki/Linux_framebuffer ; je pense que tu y trouveras ton buffonheur !

Ok Nil, je lis ça.

Brunni (./12) :
Sisi je vois où il veut en venir, mais je crains que ça va être un truc trop gros parce qu'il veut tout maîtriser, et il ne pourra pas faire beaucoup plus évolué que ce qu'il faisait sur TI. Pour ça que je préfère le mettre en garde c'est tout ^^

Je veux en venir où ? Tu m'as télépathé toi ?

Halte au télécharg... à la télépathie illégale !

j'aurais dit fbdev pour accéder au buffer vidéo de manière indépendante du driver.

Folco (./14) :
Ok Nil, je lis ça.

Brunni (./12) :
Sisi je vois où il veut en venir, mais je crains que ça va être un truc trop gros parce qu'il veut tout maîtriser, et il ne pourra pas faire beaucoup plus évolué que ce qu'il faisait sur TI. Pour ça que je préfère le mettre en garde c'est tout ^^

Je veux en venir où ? Tu m'as télépathé toi ?

Non mais vanne à part je commence à connaître vu que tes problématiques sont les mêmes depuis quelques temps, sur TI et maintenant PC. A moins que ce soit une absolue nécessité de rester low-level même sur PC, je te déconseille cordialement c'est tout. Bref bonne chance.

Je veux pouvoir faire une capture d'écran de mon PC en mode "console émulée en mode graphique", tu m'expliques comment je fais ça sous X et avec une fenêtre ?

Suffisait de le dire :
http://wiki.linuxquestions.org/wiki/Framebuffer

For example copying the framebuffer to a file (effectively making a raw screenshot) can be done with:

cat /dev/fb0 > somefile

Te restera juste à convertir le fichier brut en format d'image standard, mais je te fais confiance

Folco (./18) :
Je veux pouvoir faire une capture d'écran de mon PC en mode "console émulée en mode graphique", tu m'expliques comment je fais ça sous X et avec une fenêtre ?

Ha ouais, c'était pas le bon moment pour dire ça.
Bon pour faire ça le fbdev cité par squalyl va très bien, et c'est facile à lire. Par contre tu ne peux pas décemment utiliser ça pour écrire à ma connaissance (il me semblait que ça faisait partie de ta question).
Ca me fait penser que c'est ce qu'ils ont dû faire pour Android, vu qu'on ne peut pas prendre de screenshot par défaut (il y a un utilitaire qui requiert le rootage qui le permet, peut être qu'il y a des pistes).

Nil ->

and the Linux framebuffer means “access method to the framebuffer under the Linux kernel”, without relying on system-specific libraries such as SVGALib or another user space software

Voilà, c'est exactement ça que je cherche, une méthode d'accès à l'écran graphique via le kernel, ie indépendant du driver utilisé et de X. Me reste plus qu'à trouver de quel headers il s'agit



cross -> vas-y casse mon rêve, c'est trop facile ça Je veux le faire en C, pour croire que c'était hardcore #snif#
Puis j'aime pas faire du "system("cat /dev/fb0 > truc");"

Mais bon, admettons que je fasse sans la commande system. Faut que je fasse un fopen de fb0 en fait, puis que je copie ce qu'il y a dedans. Maintenant, quelques questions se posent :
- comment être sûr que l'écran physique affiche fb0 (parce que je suppose qu'il y a aussi fb1, fb2 etc... ce sont d'autres écrans physiques ??)
- comment récupérer les dimensions de l'écran ?
- comment récupérer la profondeur de couleur ?
- comment récupérer le format du fichier ?

En bref, où trouver la doc de cette pu***n d'api ?



recross -> Ok, je m'en bats d'écrire, je verrai ça après en fait. Pour le moment, je veux lire

http://en.tldp.org/HOWTO/Framebuffer-HOWTO.html
http://www.linux-fbdev.org/HOWTO/index.html

Bonne lecture

Folco (./22) :
- comment être sûr que l'écran physique affiche fb0 (parce que je suppose qu'il y a aussi fb1, fb2 etc... ce sont d'autres écrans physiques ??)

probablement

Folco (./22) :
- comment récupérer les dimensions de l'écran ?

ioctl

Folco (./22) :
- comment récupérer les dimensions de l'écran ?

ioctl

Folco (./22) :
- comment récupérer le format du fichier ?

ioctl

de rien

http://en.tldp.org/HOWTO/Framebuffer-HOWTO/x591.html#AEN593
linux fonctionne sur ST?

squalyl (./23) :
linux fonctionne sur ST?

Non, vu que y'a pas de MMU (enfin peut-être qu'il existe une version de µCLinux qui marche, je sais pas, mais pas le Linux "classique" en tout cas). Par contre il tourne sur Atari TT et Falcon, qui sont les successeurs du ST et qui ont des modes graphiques compatibles avec ce dernier, oui.

Zerosquare -> j'ai trouvé ces deux tutos en effet, je suis en train de lire le premier, et le second date d'il y a 12 ans. J'en ai lu une partie avant de m'en rendre, mais merci.

squalyl -> ok, ça veut dire "démerde-toi avec le kernel" en gros ?

Oh ben t'as qu'à regarder les sources, eux ils sont à jour. C'est la méthode open-source normale non ?

FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO, ...

Zerosquare (./24) :

squalyl (./23) :
linux fonctionne sur ST?

Non, vu que y'a pas de MMU (enfin peut-être qu'il existe une version de µCLinux qui marche, je sais pas, mais pas le Linux "classique" en tout cas). Par contre il tourne sur Atari TT et Falcon, qui sont les successeurs du ST et qui ont des modes graphiques compatibles avec ce dernier, oui.

Par contre, si je ne m'abuse, MiNT fonctionne sur ST (même si ça n'est pas un "vrai" Linux, ça s'en rapproche quand même pas mal).

Je débarque (en me demandant comment j'ai pu louper ce topic hier soir...) mais est-ce que tu as regardé DirectFB ?
C'est une couche d'abstraction légère au dessus du framebuffer (avec à priori de l'accélération matérielle pour certaines cartes vidéo) qui peut faire tourner un serveur X ou en fait tourner sur un serveur X...
D'ailleurs il me semble que SDL aussi peut tourner en framebuffer pur (ou au dessus de DirectFB), et être utilisé en back-end de DirectFB...
Enfin si c'est ce que tu veux faire (lib graphique en framebuffer) ça existe déjà quoi (Ça ne t'interdit pas de le refaire à titre éducatif ou si tu penses pouvoir faire mieux bien sûr)
Sinon utiliser DirectFB et/ou SDL sera bien plus simple (Je dirais bien "plus fiable" aussi, mais...) que de tout faire toi-même...

Pour la capture d'images en fb, il existe un utilitaire qui fait ça mais j'ai plus le nom en tête par contre... (Un truc du style fbcap je pense) Mais sauf si le système a évolué depuis, ça ne fonctionne pas avec l'accélération vidéo (Donc sous X)
Je vais pas t'expliquer les détails techniques parce que ma connaissance du système graphique merdique de Linux a ses limites et que je dirais quasi-certainement une connerie, mais c'est une constation que j'ai faite par moi-même: Le résultat peut être valide dans certains cas ou complètement pourrave dans d'autres. Ça va dépendre du driver vidéo utilisé, de la méthode de rendu utilisée, de ce que tu captures, à quel moment, etc. Bref, c'est pas fiable dans ce cas. (Typiquement, tu peux te retrouver avec des rectangles blancs ou incohérents sur l'image capturée)