J'ai eu du succès avec les quelques expériences suivantes.
Tout d'abord, découvrez si X utilise TrueColor RGB rembourré à 32 bits (ou supposez simplement que c'est le cas). Vérifiez ensuite si vous avez l'autorisation d'écriture sur fb0 (et qu'elle existe). Si ceux-ci sont vrais (et je m'attends à ce que de nombreux kits d'outils/bureaux/PC modernes puissent les utiliser par défaut), vous devriez pouvoir faire ce qui suit (et si ces valeurs par défaut ne tiennent pas, vous pouvez probablement encore avoir du succès avec les tests suivants bien que les détails puissent varier) :
Test 1 :ouvrez un terminal virtuel (en X) et tapez :$ echo "ddd ... ddd">/dev/fb0 où le ... est en fait quelques écrans pleins de d. Le résultat sera une ou plusieurs lignes (partielles) de gris en haut de votre écran, selon la longueur de votre chaîne d'écho et la résolution de pixels que vous avez activée. Vous pouvez également choisir n'importe quelle lettre (les valeurs ascii sont toutes inférieures à 0x80, donc la couleur produite sera un gris foncé .. et faites varier les lettres si vous voulez autre chose que du gris). Évidemment, cela peut être généralisé à une boucle shell ou vous pouvez cat un gros fichier pour voir l'effet plus clairement :par exemple :$ cat /lib/libc.so.6>/dev/fb0 afin de voir les vraies couleurs de certains fsf supporters;-P
Ne vous inquiétez pas si une grande partie de votre écran est écrasée. X a toujours le contrôle du pointeur de la souris et a toujours son idée de l'endroit où les fenêtres sont mappées. Tout ce que vous avez à faire est de saisir n'importe quelle fenêtre et de la faire glisser un peu pour effacer le bruit.
Test 2 :cat /dev/fb0> xxx puis changez l'apparence de votre bureau (par exemple, ouvrez de nouvelles fenêtres et fermez les autres). Enfin, faites l'inverse :cat xxx> /dev/fb0 afin de récupérer votre ancien bureau !
Ha, eh bien, pas tout à fait. L'image de votre ancien bureau est une illusion, et vous vous en passerez rapidement lorsque vous ouvrirez n'importe quelle fenêtre en plein écran.
Test 3 :écrivez une petite application qui récupère un vidage précédent de /dev/fb0 et modifie les couleurs des pixels, par exemple, pour supprimer la composante rouge ou augmenter le bleu, ou inverser le rouge et le vert, etc. Puis réécrivez ces pixels dans un nouveau fichier que vous pourrez regarder plus tard via l'approche simple du shell du test 2. Notez également que vous aurez probablement affaire à des quantités B-G-R-A de 4 octets par pixel. Cela signifie que vous souhaitez ignorer tous les 4 octets et traiter également le premier de chaque ensemble comme composant bleu. "ARGB" est gros-boutien, donc si vous visitez ces octets en augmentant l'index d'un tableau C, le bleu viendrait en premier, puis le vert, puis le rouge... c'est-à-dire B-G-R-A (pas A-R-G-B).
Test 4 :écrivez une application dans n'importe quel langage qui boucle à la vitesse de la vidéo en envoyant une image non carrée (pensez xeyes) à une partie de l'écran afin de créer une animation sans aucune bordure de fenêtre. Pour des points supplémentaires, faites bouger l'animation sur tout l'écran. Vous devrez vous assurer de sauter un grand espace après avoir dessiné une petite rangée de pixels (pour compenser la largeur de l'écran qui est probablement beaucoup plus large que l'image animée).
Test 5 :jouez un tour à un ami, par exemple, étendez le test 4 pour qu'une image d'une personne animée apparaisse sur son bureau (peut-être vous filmez-vous pour obtenir les données de pixel), puis marchez vers l'un de ses bureaux importants dossiers, ramasse le dossier et le déchire, puis commence à rire hystériquement, puis une boule de feu sort et engloutit tout son bureau. Bien que tout cela ne soit qu'une illusion, ils peuvent paniquer un peu... mais utilisez cela comme une expérience d'apprentissage pour montrer Linux et l'open source et montrer à quel point c'est beaucoup plus effrayant pour un novice qu'il ne l'est en réalité. [les "virus" sont généralement des illusions anodines sur Linux]
Je pense écrire un programme basé sur un framebuffer, simplement parce que j'ai besoin de pouvoir faire défiler (cascade SDR). Voir https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=232493&p=1425567#p1425567 Le test de défilement que je considère comme réussi. Dans ces 2 structures que nous récupérons par ioctl pour info, il y a aussi des trucs sur la profondeur de couleur. Vous semblez avoir basé votre programme sur le même exemple que moi. Comment obtenir la couleur des pixels à partir du framebuffer sous Linux (Raspberry Pi)
Le mien fonctionne bien sur mon Raspberry Pi, avec X ou non. Cela n'a aucun effet sur l'écran de mon ordinateur portable. Cela a un /dev/fb0, le programme s'exécute et les chiffres semblent corrects, mais cela ne fait rien visuellement. Peut-être que c'est un double tampon ou quelque chose comme ça.
Sous X, il ne cause aucun dommage. Si vous faites glisser certaines fenêtres pour que les choses se redessinent, tout revient. Ensuite, j'ai décidé de sauvegarder ce qui est à l'écran et de le remettre quand j'ai terminé, ça marche aussi. Une fenêtre que j'ai déplacée et remise fonctionne comme si je n'y avais jamais touché. X ne se rend pas compte que j'ai joué avec le tampon d'écran, il sait ce qu'il y a mis et enregistre les clics de souris en conséquence. Si je déplaçais une fenêtre et que je ne la remettais pas en place, les clics fonctionneraient toujours là où ils se trouvaient.
Je dirais que soyez prudent avant d'essayer d'écrire sur /dev/fb0, comme suggéré ci-dessus. Je l'ai essayé sous Xin Ubuntu 10.04 et a) rien ne s'est passé visuellement, b) il a détruit toutes les fenêtres du shell, même les autres ttys, entraînant des erreurs de noyau et un manque de fonctionnalité.
Si vous utilisez X11, vous DEVEZ passer par les API X11 pour dessiner à l'écran. Faire le tour du serveur X est très cassé (et, souvent, comme vous l'avez vu, ne fonctionne pas). Cela peut également provoquer des plantages ou simplement une corruption générale de l'affichage.
Si vous voulez pouvoir exécuter partout (à la fois sur console et sous X), regardez SDL ou GGI. Si vous ne vous souciez que de X11, vous pouvez utiliser GTK, QT ou même Xlib. Il y a beaucoup, beaucoup d'options...