Comment utiliser / dev / fb0 comme console à partir de l'espace utilisateur, ou y envoyer du texte

J'ai donc un modèle Palm Pre (P100EWW d'origine) sur lequel j'ai activé le mode développeur et installé un chroot Debian Squeeze. Fonctionne très bien. J'ai l'intention de l'utiliser pour TOUT (pair bittorrent, serveur Web) mais pour un téléphone.

J'ai remarqué que si j'en fais un, cat /dev/urandom > /dev/fb0il écrit des pixels aléatoires sur l'écran jusqu'à ce qu'une No space left on deviceerreur soit générée. Génial, maintenant je peux utiliser l'écran.

Donc, quel genre d'utilitaires existe-t-il qui A) me permettra d'utiliser / dev / fb0 comme console, je peux produire du texte vers ou B) rendre le texte sur / dev / fb0 à partir de la ligne de commande.

Je ne sais pas encore pour recompiler le noyau pour cela (j'adorerais éventuellement supprimer complètement WebOS et le transformer en un serveur ARM minimal), donc les outils de l'espace utilisateur s'ils existent sont ce que je demande. Je préfère également effectuer le rendu directement dans / dev / fb0 et ne pas utiliser X.

Pour utiliser le framebuffer comme console, vous avez besoin du fbdevmodule. 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 GUI écrits pour cela.

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 pour l'instant 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 inclus:

• zhcon ( Debian ) - un terminal virtuel de l'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 codages non UTF ISO 2022; sa faiblesse particulière est le codage UTF.
• fbterm ( Debian ) - un terminal virtuel de l'espace utilisateur qui a engendré plusieurs fourches, y compris 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 .
• Le fbpad d' Ali Gholami Rudi - un terminal virtuel d'espace utilisateur minimaliste qui ne dépend pas des bibliothèques X.
• Les outils console-terminal-emulatoret console-fb-realizerdans nosh - un terminal virtuel de l'espace utilisateur destiné à 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 logindserveur 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 framebuffer. Il a également écrit une visionneuse PDF directe à framebuffer, une visionneuse VNC, un lecteur multimédia et un lecteur du Coran.

Une comparaison côte à côte complète dépasse la portée de cette réponse; mais voici quelques points qui sont pertinents pour 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 d'entrée CJK, etc. Ce ne sont pas des clients X, mais ils ont des dépendances de bibliothèques X. fbpadet les outils nosh par conception n'utilisent aucune bibliothèque X.
• Les programmes qui utilisent des bibliothèques X pour la gestion des polices utilisent bien sûr des 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 l' bdftobogloutil; et on convertit TTF en polices "tinyfont" qui sont utilisées par fbpad avec l'outil ft2tf ( Arch ).
  • L' console-fb-realizeroutil nosh utilise les mêmes polices "vt" que le nouveau sous - système de terminal virtuel du noyau FreeBSD 10.1 , et partage ainsi l'outil de manipulation de polices FreeBSD vtfontcvtpour 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 complet compatible ISO 9995-3 avec le groupe ISO "commun" 2. On convertit les fichiers kbdmap BSD à ce format avec l' console-convert-kbdmapoutil. 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'invocation 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 se reproduire login.
  • Les outils nosh ont été conçus pour s'intégrer à un système existant /etc/ttys(BSD), /etc/inittab(système Linux 5 init) ou à un autre système, auquel ils laissent le travail de génération de getty / login / shell. console-fb-realizern'a besoin que de privilèges suffisants pour ouvrir le framebuffer et les périphériques d'événements d'entrée, qui ne doivent pas être des privilèges de superutilisateur, et pour accéder aux FIFO et aux fichiers ordinaires gérés par console-terminal-emulator, qui à leur tour n'ont pas besoin de privilèges spéciaux.

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

• bogl-bterm est bien sûr basé sur 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.
• À mi-chemin entre l'écriture d'un programme qui utilise une bibliothèque de tampons d'images pour faire son propre rendu et un programme qui crache des séquences d'échappement à ce qu'il pense être un terminal: le terminal virtuel de l'espace utilisateur nosh est modulaire et se divise en pièces composantes. On ne peut tout simplement pas utiliser console-terminal-emulator.

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

  En passant: Observez que c'est l'opposé de l' intégration avec BRLTTY , qui utilise console-terminal-emulatormais ne s'exécute pas console-fb-realizer.

Si vous pouvez chatter /dev/urandom > /dev/fb0et obtenir des pixels aléatoires à 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 peut être un peu longue, car si vous n'utilisez pas de console, vous devrez imprimer vous-même les pixels des caractères. Heureusement, quelqu'un a fait le travail difficile, nous devons donc simplement le combiner.

Dans la boîte occupée ou dans votre raspi, vous devriez avoir un fbsetbinaire. Cela pourrait vous aider à découvrir vos paramètres en tant que dimensions d'écran.

Dans mon imbriqué 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, nettoyez votre écran, nous devons vous assurer d'obtenir les dimensions correctement.

Par chance, mon busybox avait un binaire fbsplash qui obtient en entrée un fichier .ppm.

Corrigez si je me trompe, mais il semble que fb0ce format soit accepté. En jetant un œil sur Portable Anymap sur Wikipedia , il existe plusieurs "sous-formats" ... fbsplash en utilise un de fantaisie avec des couleurs, et ainsi de suite ... mais nous voulons pouvoir imprimer simplement quelque chose de lisible. Utilisons le P1 codé en ASCII pour des raisons de simplicité. Si nous pouvions imprimer une ligne verticale, nous saurions que nos dimensions sont correctes. Essayons:

Une ligne verticale dans un type P1 ppm 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, passer en mode commande (esc), puis taper les caractères suivants:

of(esc)479a 0(esc)yy271p

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

Ok, je triche ... ce n'est pas juste une ligne là ... c'est environ 8 ... mais quand ça ne marche pas (nous avons de mauvaises dimensions ou nous avons de l'espace à la fin, avoir une seule ligne c'est beaucoup Plus facile).

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

Avec un petit ajustement, développez son programme simple pour imprimer à la fplace Xet 0au 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 code de caractère.

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

J'ai également testé cette solution sur un Raspberry Pi et cela a fonctionné. Le système me dit que je n'ai pas la réputation de publier plus de 2 liens. Jusqu'à ce que j'obtienne ceci, vous devez vous fier à ma parole: D

Pour la console, vous pouvez faire écho à /dev/consoleou utiliser Syslog, et en fonction de divers autres paramètres, il peut apparaître sur la console.

Pour les images, j'ai juste essayé d'attacher un fichier bmp à fb0 et cela a fonctionné! (sortof - plusieurs copies, taille plus petite)

J'ai trouvé un programme bmp-to-framebuffer ici . Cela devrait être un parfait exemple du format attendu par le fb0. Il existe également fbiun programme pour écrire directement dans le tampon de trame.

C'est un vieux post mais je comprends normalement que vous avez besoin d'une console framebuffer (fbcon) pour exécuter la console sur framebuffer. C'est dans la configuration. (pilotes de périphériques / graphiques / affichage de la console ..)