Comment utiliser /dev/fb0 en tant que console à partir de l'espace utilisateur ou y envoyer du texte

Plusieurs personnes ont répondu aux parties de votre question traitant du noyau et mettant des images (plutôt que du texte) sur le framebuffer, mais jusqu'à présent, le reste reste sans réponse. Oui, vous pouvez utiliser le sous-système de terminal virtuel du noyau pour créer une soi-disant console framebuffer . Mais il existe plusieurs outils qui vous permettent d'utiliser le périphérique framebuffer pour créer des terminaux virtuels dans l'espace utilisateur . Ceux-ci incluent :

zhcon (Debian) — un terminal virtuel en espace utilisateur conçu pour gérer les E/S CJK bien mieux que le sous-système du noyau. Sa force particulière réside dans la gestion des encodages non UTF ISO 2022; sa faiblesse particulière est les encodages UTF.
fbterm (Debian) — un terminal virtuel en espace utilisateur qui a engendré plusieurs forks dont jfbterm. Il a un tas de plug-ins de méthode d'entrée CJK.
bogl-bterm (Debian) — un terminal virtuel de l'espace utilisateur qui a engendré des fourches telles que niterm.
Fbpad d'Ali Gholami Rudi :un terminal virtuel minimaliste en espace utilisateur qui ne dépend pas des bibliothèques X.
Le console-terminal-emulator et console-fb-realizer tools in nosh — un terminal virtuel de l'espace utilisateur visant à répliquer les terminaux virtuels du noyau Linux et FreeBSD/PC-BSD. Il n'a pas non plus de dépendances sur les bibliothèques X.
kmscon — un terminal virtuel de l'espace utilisateur qui est étroitement lié au logind serveur dans systemd et ses notions de "sièges".

Ali Gholami Rudi en particulier a produit plus qu'un simple émulateur de terminal pour le travail de framebuffer. Il a également écrit un visualiseur PDF direct vers framebuffer, un visualiseur VNC, un lecteur multimédia et un lecteur de Coran.

Une comparaison complète côte à côte dépasse la portée de cette réponse; mais voici quelques points pertinents à la question :

Comme indiqué, plusieurs des programmes de terminaux virtuels de l'espace utilisateur utilisent des bibliothèques X pour la gestion des polices, le mappage du clavier, les méthodes de saisie CJK, etc. Ce ne sont pas des clients X, mais ils ont des dépendances des bibliothèques X. fbpad et les outils nosh de par leur conception n'utilisent aucune bibliothèque X.
Les programmes qui utilisent les bibliothèques X pour la gestion des polices utilisent bien sûr les polices X. Les autres prennent d'autres dispositions.
- bogl-bterm et fbpad ont tous deux leurs propres formats de police idiosyncratiques. On convertit les polices BDF en polices BOGL avec le bdftobogl outil; et l'autre convertit TTF en polices "tinyfont" utilisées par fbpad avec l'outil ft2tf (Arch).
- La bouffe console-fb-realizer utilise les mêmes polices "vt" que le nouveau sous-système de terminal virtuel du noyau FreeBSD 10.1, et partage donc l'outil de manipulation de polices FreeBSD vtfontcvt pour convertir les polices BDF.
Les programmes qui utilisent les bibliothèques X utilisent le mappage du clavier X. Quant aux autres :
- Les outils nosh ont leur propre format de carte de clavier idiosyncrasique, destiné à fournir un clavier compatible ISO 9995-3 complet avec le groupe ISO "commun" 2. On convertit les fichiers kbdmap BSD à ce format avec le console-convert-kbdmap outil. Encore une fois, ces fichiers kbdmap sont ceux utilisés avec le sous-système FreeBSD/PC-BSD vt.
- fbpad ne fait pas du tout son propre mappage de clavier et s'appuie sur la présence du sous-système de terminal virtuel du noyau et de son mécanisme de mappage de clavier pour cela.
Il y a une certaine variation dans l'appel et les privilèges requis :
- zhcon, fbterm, bogl-bterm, fbpad et kmscon fonctionnent sur la base que l'émulateur de terminal génère le programme shell/login sur le terminal, directement, en tant que processus enfant. Ils ont besoin de privilèges de superutilisateur pour générer login .
- Les outils nosh ont été conçus pour s'intégrer à un /etc/ttys existant (BSD), /etc/inittab (Système Linux 5 init ), ou un autre système, auquel ils laissent le travail de générer getty/login/shell. console-fb-realizer n'a besoin que de suffisamment de privilèges pour ouvrir le framebuffer et les périphériques d'événement d'entrée, qui n'ont pas besoin d'être des privilèges de superutilisateur, et pour accéder aux FIFO et aux fichiers ordinaires gérés par console-terminal-emulator , qui à son tour n'a besoin d'aucun privilège spécial.

Tous ces éléments sont des émulateurs de terminaux bien sûr. Si vous souhaitez supprimer l'émulation de terminal et placer plus directement du texte sur le framebuffer, vous avez plusieurs choix :

bogl-bterm est bien sûr basé sur la Ben's Own Graphics Library de Ben Pfaff une bibliothèque d'E / S de framebuffer conçue pour être utilisée dans les environnements de configuration / sauvetage du système (et "pour les interfaces graphiques des PDA"). Vous pouvez bien sûr écrire des programmes qui l'utilisent directement.
Pour une maison à mi-chemin entre l'écriture d'un programme qui utilise une bibliothèque de framebuffer pour faire son propre rendu et un programme qui crache des séquences d'échappement vers ce qu'il pense être un terminal :le terminal virtuel de l'espace utilisateur nosh est modulaire, et se décompose en éléments constitutifs. On ne peut tout simplement pas utiliser console-terminal-emulator .

console-fb-realizer utilise un fichier d'affichage avec un tableau de cellules de caractères, comme /dev/vcsa* mais un fichier ordinaire (pas un fichier de périphérique spécial de caractères) et avec des points de code Unicode, des attributs ECMA-48 et une couleur RVB 24 bits. Ainsi, on peut l'exécuter et simplement écrire caractère + attribut + couleur directement dans le fichier de tableau de cellules de caractères, laissant console-fb-realizer faire le rendu de la police dans le framebuffer.

En aparté :notez que c'est le contraire de l'intégration avec BRLTTY, qui utilise console-terminal-emulator mais n'exécute pas console-fb-realizer .

Pour utiliser le framebuffer comme console, vous avez besoin du fbdev module. Vous devrez peut-être recompiler votre noyau.

Vous pouvez également être intéressé par le projet DirectFB, qui est une bibliothèque qui facilite l'utilisation du framebuffer. Il existe également des applications et des environnements graphiques déjà écrits pour cela.

Si vous pouvez cat /dev/urandom > /dev/fb0 et obtenez des pixels aléatoires sur l'écran, vous avez tout ce dont vous avez besoin.

Dans mon cas, j'avais besoin de vider des informations textuelles. J'ai testé cela dans busybox et raspi, donc cela pourrait fonctionner pour vous. La réponse pourrait être un peu longue, car si vous n'utilisez pas de console, vous devrez imprimer le pixels de caractères vous-même. Heureusement, quelqu'un a fait le travail difficile, nous avons donc juste besoin de le combiner.

Dans busybox ou dans votre raspi vous devriez avoir un fbset binaire. Cela peut vous aider à trouver vos paramètres en tant que dimensions de l'écran.

Dans mon intégré ressemble à ceci :

# fbset

mode "480x272-1"
    # D: 0.104 MHz, H: 0.207 kHz, V: 0.657 Hz
    geometry 480 272 480 272 16
    timings 9600000 3 3 0 32 17 11
    accel false
    rgba 5/0,6/5,5/11,0/0
endmode

La partie importante ici est la largeur 480 et la hauteur 272 pixels.

Comme vous l'avez mentionné, vous pouvez remplir l'écran avec cat /dev/urandom > /dev/fb0

et vous pouvez l'effacer avec cat /dev/zeros > /dev/fb0

Ensuite, effacez votre écran, nous devons vous assurer d'obtenir les dimensions correctement.

Par chance, ma busybox avait un binaire fbsplash qui reçoit en entrée un fichier .ppm.

Corrigez si je me trompe, mais il semble que fb0 accepte ce format.En jetant un coup d'œil sur Portable Anymap sur Wikipedia, il existe plusieurs "sous-formats"... fbsplash en utilise un de fantaisie avec de la couleur, et ainsi de suite... mais nous voulons pouvoir simplement imprimer quelque chose de lisible. Utilisons le P1 codé en ASCII par souci de simplicité. Si nous pouvions imprimer une ligne verticale, nous saurions que nos dimensions sont correctes. Essayons :

Une ligne verticale dans un ppm de type P1 devrait ressembler à ceci :

P1
480 272
f 0 0 0 0 ... 0 
f 0 0 0 0 ... 0
... 
f 0 0 0 0 ... 0

Donc, il y aura 272 lignes, 959 caractères de large. La documentation indique qu'il devrait être 1 au lieu de f... sur busybox et raspi f était plus lumineux.

Il est important que vous n'ayez pas d'espace après les 0...Cette tâche peut être un peu fastidieuse...vous feriez mieux d'utiliser un éditeur de texte qui vous aide.Dans vim, vous pouvez copier les deux premières lignes, passez en mode commande ( esc), puis saisissez les caractères suivants :

of(esc)479a 0(esc)yy271p

Bien sûr, j'utilise mes dimensions, vous devriez utiliser les vôtres.Cat ce fichier à /dev/fb0 , cela devrait ressembler à :

Ok, je triche... il n'y a pas qu'une ligne là... c'est environ 8... mais quand ça ne marche pas (on a des dimensions erronées ou on a de la place au bout, avoir une seule ligne c'est beaucoup plus facile).

Si vous êtes arrivé jusque-là, nous n'avons plus qu'à imprimer les bons pixels pour les voir sous forme de caractères. Grâce à Marcel Sondaar et à son dépôt sur GitHub, nous n'aurons pas besoin de dessiner chaque caractère.

Avec un petit ajustement, on étend son programme simple pour imprimer f au lieu de X et 0 au lieu d'espaces, insérez des espaces entre chaque caractère, ajoutez l'en-tête et nous avons un fichier .ppm avec la lettre correspondant à son charcode.

Un petit pas de plus et vous n'obtenez pas un caractère en entrée, mais une ligne. Cat un fichier, un tuyau vers votre programme et une sortie vers /dev/fb0 et vous obtenez une sortie texte :

J'ai testé cette solution aussi sur un raspberry pi et ça a marché. Le système m'indique que je n'ai pas la réputation de poster plus de 2 liens. Jusqu'à ce que j'obtienne ceci, vous devez compter sur ma parole :D