Bonjour à tous,
voila je sais qu'en absence de noyau on peut avec un petit programme fait maison (qui remplace le noyau) afficher directement du code ascii sur notre écran via le frame buffer.
On peut dirrectement communiquer avec la carte vidéo via l'adresse 0x000B8000. Mais on ne peut afficher que du code ascii, je n'ai rien vu pour afficher des lignes droites, ou juste un point au milieux de l'écran.
Peut on réaliser ce genre de chose via le framebuffer ?
Le serverX doit communiquer avec la carte vidéo pour gérer les interfaces graphiques, or dans /dev/ je n'ai vu aucun périphérique vidéo donc je ne vois pas comment serverX pour faire un open puis write ou mmap pour pouvoir afficher des informations à l'écran.
Merci d'avance pour votre aide
# frame buffer device
Posté par Anonyme . Évalué à 2.
/dev/fbdev
il y a quelques années du moins, il me semble que la bibliotheque sdl_directfb permet de faire ce que tu souhaite avec un peu de facilité (jamais fais mais il y a quelques jeu qui l'utilise)
man fbdev
# et le serveur X
Posté par Anonyme . Évalué à 2.
je me souviens maintenant d'avoir lancer un serveur X sur /dev/fbdev, a l’époque il s'agissait de Xfree avec le drivers fbdev (ou un truc du genre) bien placé dans le fichier de configuration bien long et abscons
# sans noyau, pas de framebuffer...
Posté par freem . Évalué à 5. Dernière modification le 29 juillet 2019 à 23:10.
Plusieurs choses: le framebuffer est une interface mise à disposition par le noyau, et relativement simple à utiliser. Donc, sans noyau, pas de framebuffer, juste du VESA ou autres joyeusetés bas niveau.
Le nom du fichier de framebuffer est /dev/fb0 sur mon linux. Il est probablement possible d'en avoir plusieurs, pour gérer du multi-écran, mais j'ignore comment.
Il faut faire partie du groupe video, et pour gérer les entrées, du groupe input, sous Debian.
Pour aider plus sur la question réelle, voici un lien qui explique comment utiliser les framebuffer de linux, entres autres, et sans bibliothèque.
Pour info, la SDL gère de manière expérimentale et super foireuse le framebuffer, et ce, en s'appuyant sur le bloatware non maintenu qu'est directfb. Pour avoir essayé, je déconseille fortement.
Tu trouveras aussi des informations (en plus du lien que j'ai passé plus haut) dans le fichier /usr/include/linux/fb.h. Pour les entrées, je te conseilles l'usage de libinput, un peu galère a utiliser, et l'usage sans udev est pas franchement bien documenté, mais ça juste marche pour moi jusqu'à présent. Restera le problème du curseur texte qui reste affiché, pour ça, /usr/include/linux/kd.h te sera utile: il faut passer le TTY en KD_GRAPHICS si ma mémoire est bonne. Le problème étant que cet appel de ioctl nécessite d'être root, je n'ai pas trouvé comment résoudre ça autrement, peut-être avec les capabilities, mais vu comment c'est documenté… bonne chance. Il doit y avoir moyen de faire autrement, c'est sûr, mais j'ai pas encore cherché. Une piste serait d'analyser le code de logiciels de ngetty ou fgetty.
Bonne chance.
[^] # Re: sans noyau, pas de framebuffer...
Posté par freem . Évalué à 3.
J'ai oublié…
/dev/fb0 n'existe pas par défaut avec mes vieux pilotes nvidia, il me faut utiliser "modprobe uvesafb" pour que ça marche. Et le résultat reste moche. Par contre, ça marche avec nouveau sans modprobe, mais les performances de nouveau sur mon vieux hardware (GeForce 8400, mais pourquoi jeter: ça marche et me suffit) sont a chier, limite pire qu'un rendu logiciel.
Je n'ai pas encore testé DRM.
Les framebuffer n'ont aucune documentation sur les *BSD, et l'on m'a dit qu'ils ne sont pas supportés, donc, ce truc super simple a utiliser (vraiment, c'est trivial) n'est utilisable que sous linux a ma connaissance.
Je pense avoir fait le tour de toutes les infos que j'ai glanées sur ce sujet, donc bonne chance.
Petit outil complémentaire: libpng est une p****n d'usine à gaz. Freetype aussi. J'ai préféré implémenter un support rudimentaire des formats psf1 et psf2 pour le texte, et utiliser libspng pour les images. Comme tout ça est pour le taf, je peux pas partager de code. Enfin, s'pas comme si l'implémentation avait été le plus difficile (enfin, si, je galère, mais pour des raisons autres que libinput, fb.h, kd.h, psf1/2 ou spng…).
[^] # Re: sans noyau, pas de framebuffer...
Posté par cosmoff . Évalué à 1.
Le lien que tu m'as donné est vachement bien fait !
petite chose que je ne comprend pas. /dev/fb0 est fourni par le noyau, donc a chaque fois, je passe par le noyau pour afficher des choses à l'écran. admettons maintenant que je veux créer mon propre noyau, et je souhaite pouvoir afficher des choses à l'écran. ma carte vidéo est forcément connectée (directement ou indirectement) a des ports de mon CPU. Mais comment je peux faire avec mon propre noyau pour afficher des choses à l'écran.
Autrement dit comment je peux envoyer des data à ma carte vidéo avec mon propre noyau fait maison.
[^] # Re: sans noyau, pas de framebuffer...
Posté par Renault (site web personnel) . Évalué à 3.
Comme tout noyau tu dois mettre en place de quoi communiquer avec ta carte graphique. Qui sera composé de plusieurs pilotes différents. Un pour prendre en charge les instructions de ta CG en particulier, notamment pour l'initialiser et une autre pour mettre en place et dialoguer via le bus de communication entre le CPU et le GPU qui est souvent du PCI express aujourd'hui.
Ensuite tu dois exposer bien entendu à tes applications de quoi envoyer des introductions graphiques via le noyau vers la CG.
[^] # Re: sans noyau, pas de framebuffer...
Posté par David Marec . Évalué à 4.
Le moins «complexe» serait de s'assurer que l'on peut attaquer la carte vidéo via une interface VGA voire SVGA/VESA-VBE.
L'adresse donnée pour afficher en mode «texte» étant justement celle du VGA, ça devrait coller.
Pour résumer, il faut passer en mode «graphique» ( via
INT 10) et coller ses pixels au bon offset à partir de0x0000A000.# L'article qu'il te faut
Posté par gUI (Mastodon) . Évalué à 2.
Je viens de tomber sur cet article, je pense qu'il est pour toi :)
https://www.linuxjournal.com/content/what-does-it-take-make-kernel-0
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.