Discussion :

[kripteks]

Salut à tous.
Disons que je veux afficher quelque chose à l'écran sous linux, est-il possible de faire ceci:

En gros:
- serveur affichage: fournis image 1
- carte graphique: affiche image 1

devient -->

- serveur affichage: fournis image 1
- moi: modifie image 1
- carte graphique: affiche image 1

Quand je dis image 1, je veux dire le fichier en question qui est modifier par le serveur d'affichage et que la carte graphique le lit pour l'afficher (, si j'ai bien compris)


Est-ce possible ?

[Kannagi]

Je sais pas ce que tu appelle 'serveur affichage' , mais pour utilisé la carte graphique sous linux il n'y a qu'un moyen utiliser opengl (opencv pour des calcul parallèle) du coup le forum C ou même le sous forum OpenGL est plus indiqué pour ce genre de question.

[kripteks]

En fait le serveur d'affichage c'est Xorg.
La lib de Xorg c'est xlib, voici un petit shéma:
xlib -> sdl , gtk, qt, etc -> 2d/context opengl.

Mon but n'est pas d'utiliser la carte graphique, mais de jouer avec l'image(le fichier) dont il va afficher à l'écran.
Je sais pas si j'ai vrai ou faux et si je peux manipuler ou non le fichier, j'ai eu une pensé que c'est une boucle:
fichier -> carte graphique -> écran -> xorg -> fichier -> carte graphique -> écran

Pour la section, le C et l'Assembleur sont bon (je crois) pour ce que j'aimerais faire, mais j'ai ajouté ici sans vraiment réfléchir.
Probablement je le ferais en C pour les débuts, mais mon but serait de l'utiliser sur un autre langage (nouveau) qui sera traduit en assembleur.
En y pensant peut-être que j'aurais plus de réponses dans la section C. Mais ici c'est plus technique, j'aurais peut-être de meilleur info. Bref suis perdu

[Kannagi]

Euh pas sur de te suivre mais si tu veux lire un fichier (bmp par exemple) , tu lis lis comme n'importe quel fichier (en C avec fopen) , ensuite tout dépend de ce que tu veux faire soit tu le met en RAM (en général en le met dans un tableau de char) et ensuite tu affiche en software (avec SDL) , sois tu l'envoie dans la CG et tu peux ensuite afficher avec opengl.

Je pense pas que l'assembleur soit bon , perso je déconseillerai de faire un programme pour Windows ou Linux , apres plus technique c'est relative le forum C est assez technique comme la section OpenGL.

[kripteks]

En fait c'est pas une image, image jpeg bmp etc.
Mais je parles le fichier qui contient "le contenu" de ce qui est afficher à l'écran.


serveur affichage->flux sortie <---> flux entrée<-carte graphique->flux sortie <---> flux entrée<-écran

[Kannagi]

Euh je ne pense pas que Xorg utilise OpenGL(ou si tu préfère la carte graphique) derrière.
Mais je n'ai pas compris ce que tu voulais faire ? Certe Xorg et la couche la plus 'basse' , mais tu peux utilise la SDL pour affichage et éventuellement OpenGL si tu veux une accélération matériel , mais la CG ne fait que ds calcul et ne gère pas vraiment affichage a proprement parler.

Du coup ceci pour ma part est completement faux :

fichier -> carte graphique -> écran -> xorg -> fichier -> carte graphique -> écran

[kripteks]

Dans tous les cas il y a bien ceci: système -> carte graphique -> écran

http://fr.wikipedia.org/wiki/Framebuffer
http://fr.wikipedia.org/wiki/M%C3%A9moire_vid%C3%A9o

Je google.




Édite
J'ai trouvé un message d'Obsidian sur un autre sujet:
"...
le framebuffer du noyau Linux : c'est une interface proposée par le kernel faite pour accéder facilement à la mémoire vidéo sans recourir à d'autres ressources.
...."

Donc si je résume:
- Pour faire un dessin et l'afficher sur l'écran (vide), il suffit que je joue dans la mémoire vidéo tout simplement.
- Pour faire un dessin au dessus du dessin du serveur Xorg, suffit aussi de jouer sur la mémoire vidéo;
mais le résultat ne sera ni beau, ni compatible avec l’environnement en cours d'utilisation;
donc il faudra utiliser xlib, sdl ou etc et avoir sa propre zone.

Merci à toi.
Et aussi à Obsidian même s'il n'est pas là, son message nous a été utile

Je met résolu.

[Obsidian]

Bonsoir,

ÉditeJ'ai trouvé un message d'Obsidian sur un autre sujet:
Merci à toi.
Et aussi à Obsidian même s'il n'est pas là, son message nous a été utile

Je ne suis jamais très loin quand on poste dans le forum assembleur. :-) Le trafic n'est pas très important.
La discussion en question : http://www.developpez.net/forums/d14...rte-graphique/

"...
le framebuffer du noyau Linux : c'est une interface proposée par le kernel faite pour accéder facilement à la mémoire vidéo sans recourir à d'autres ressources.
...."

En fait, d'une manière plus générale, le framebuffer est justement le nom que l'on donne à la zone de RAM qui est scannée automatiquement par la carte vidéo pour en convertir linéairement le contenu en signaux pilotant le moniteur, et donc en pixels. C'est le fonctionnement normal de toutes les cartes vidéos depuis la fin des années 1970 jusqu'au matériel contemporain, mais comme cela demande par nature un minimum de RAM pour que cela fonctionne efficacement (même en mode texte), il a fallu attendre que les techniques de production de celle-ci se développe un peu. À titre indicatif, le MO5 n'était doté en tout et pour tout que de 64 Ko de mémoire vive (tous usages confondus, vidéo comprise) et c'était déjà beaucoup pour l'époque. C'est pour cela que la page Wikipédia consacrée au sujet montre que, par extension, c'était aussi le nom que l'on donnait au matériel (formellement la carte vidéo, donc) avant que cela devienne un fondamental de tous les ordinateurs.

Avant ça, les machines pilotaient soit un téléscripteur (formellement une machine à écrire électrique), d'où les teletypes abrégés en « TTY » que l'on utilise encore aujourd'hui pour désigner les consoles UNIX, soit un tube cathodique qui tenait plus de l'oscilloscope que du téléviseur et s'en servaient pour y tracer des segments de droite (les vecteurs). Cette dernière technique est restée confidentielle dans les milieux spécialisés, à l'exception notable de la console Vectrex : http://fr.wikipedia.org/wiki/Vectrex

Sous Linux, « framebuffer » est, là encore par extension, le nom que l'on donne à l'interface noyau permettant d'accéder directement à ce framebuffer, via « /dev/fb ».

Donc si je résume:
- Pour faire un dessin et l'afficher sur l'écran (vide), il suffit que je joue dans la mémoire vidéo tout simplement.

Dans l'absolu, oui.

- Pour faire un dessin au dessus du dessin du serveur Xorg, suffit aussi de jouer sur la mémoire vidéo;

Ça dépend de ce que tu entends par « au dessus ».

mais le résultat ne sera ni beau, ni compatible avec l’environnement en cours d'utilisation;
donc il faudra utiliser xlib, sdl ou etc et avoir sa propre zone.

Pour faire court, oui. En pratique, lorsque l'on accorde la gestion de la mémoire vidéo à X-Window, il faut le laisser le faire. Ça ne donne jamais rien de bon lorsque deux programmes utilisent un même périphérique simultanément et sans concertation. Le problème serait le même avec une imprimante, par exemple.

D'autre part, X-Window est fait pour être un serveur d'affichage. Ça veut dire qu'il ne tourne pas nécessairement sur la même machine que l'application qui l'exploite à travers la X-Lib. C'est d'ailleurs très marrant de voir une application s'exécuter dans un terminal, avoir tous les messages tomber proprement dans la console, et voir la partie graphique être rendue sur l'écran d'à côté, voire même dans le bureau du collègue la porte à côté, surtout quand c'est xeyes. Cette partie serveur va d'ailleurs tomber un peu en désuétude avec Wayland et c'est dommage (à mon goût).

On note également que Linux garde quand même la main sur sa ressource et peut la reprendre si nécessaire : c'est le cas quand on va changer de console virtuelle. Traditionnellement, les distributions de Linux sont configurées pour allouer six consoles virtuelles à getty pour qu'elles fonctionnent comme des terminaux ordinaires et X-Window, en s'initialisant, alloue la première disponible, donc la numéro 7 (ce n'est plus vrai non plus avec les dernières Fedora et avec systemd qui gère le tout différement et qui lance d'abord X sur la première console). Quand on change de console avec (Ctrl-)Alt+F1 à F7, Linux sauve le contexte courant, demande à l'application de se mettre en veille, change le mode graphique si nécessaire et redonne la main à l'application qui gère la console de destination.

La XLib permet de dialoguer avec le serveur X et de lui expliquer ce que l'on veut qu'il affiche. La SDL est intéressante car elle est non seulement conçue pour être facile à utiliser mais également pour s'interfacer avec un grand nombre d'environnements différents ;

Regarde également la SVGALib que l'on utilisait relativement fréquemment sous Linux. Elle est faite elle-aussi pour exploiter directement les ressources locales de la machine, initialiser les modes graphiques directement en fonction des capacités de l'hôte et t'offrir à la fois des primitives graphiques et la possibilité d'obtenir un pointeur vers la mémoire vidéo.

[kripteks]

Merci.

Malheureusement j'ai pas "svgalib" d'installable sur la branche actuel que j’utilise dans ma distribution linux, pourtant il est présent sur celui d'avant et suivant
Ça compile pas à cause de l'include <vga.h>.

Je trouverais bien un moyen.

[chrtophe]

Ce que tu souhaites faire n'est pas très clair. De ce que j'en ai compris, tu veux manipuler l'image en mémoire avant de l'afficher. X a des structures pour ceci, mais je pense que c'est pas assez rapide pour en faire en masse. SDL doit te permettre de gérer aussi cela. Selon le système que tu vas utiliser regardes du coté du double-buffering.

Je considères uniquement la 2D pour cela.

[kripteks]

Mon but n'est pas faire de l'image propre, j'ai pris ça comme un exemple simple.
Ce que je voulais un moment c'est d'afficher des pixels par-dessus ce que X voulais afficher: donc je voulais remplacer les pixels de X par mes propres pixels à tel ou tel endroits.
Mais j'ai compris que c'était une mauvaise idée.

[Obsidian]

Merci.

Malheureusement j'ai pas "svgalib" d'installable sur la branche actuel que j’utilise dans ma distribution linux, pourtant il est présent sur celui d'avant et suivant
Ça compile pas à cause de l'include <vga.h>.

Dans ce cas, va la chercher ici : http://www.svgalib.org/
Et compile-la toi-même. C'est un projet qui reste très léger, et relativement facile à utiliser.

À titre indicatif, j'ai écrit mon tout premier projet en C, après le « hello world » de rigueur, en utilisant la SVGALib (en 1998).

Mon but n'est pas faire de l'image propre, j'ai pris ça comme un exemple simple.
Ce que je voulais un moment c'est d'afficher des pixels par-dessus ce que X voulais afficher: donc je voulais remplacer les pixels de X par mes propres pixels à tel ou tel endroits.
Mais j'ai compris que c'était une mauvaise idée.

Essaie également le framebuffer Linux. L'ennui est que cela dépend évidemment du mode et du type de carte que tu utilises et que, par conséquent, il faut choisir le bon module. Par contre, tu peux toujours utiliser les anciens modes VGA qui restent compatibles partout. Du coup :

• Quitte X-Window et saute vers une console virtuelle avec Ctrl-Alt-F1, F2, F3… celle que tu veux ;
• Assure-toi que le mode texte que tu y vois est quand même émulé via le framebuffer. Sinon, peu importe ;
• Passe root ;
• Charge le module en question avec « modprobe vga16fb » ;
• Tapes dmesg et regarde les infos données par le modules à l'initialisation. Il a même le bon goût de te dire à quel endroit en mémoire il a mappé le tout ;
• Sers-toi de dmesg comme générateur de données et écris-en une partie dans le framebuffer avec « dmesg | head > /dev/fb0 » ;
• Amuse-toi.