Come utilizzare /dev/fb0 come console dallo spazio utente o inviare testo ad esso

Diverse persone hanno risposto alle parti della tua domanda relative al kernel e all'inserimento di immagini (piuttosto che testo) sul framebuffer, ma finora il resto rimane irrisolto. Sì, puoi utilizzare il sottosistema del terminale virtuale del kernel per creare una cosiddetta console framebuffer . Ma ci sono diversi strumenti che ti consentono di utilizzare il dispositivo framebuffer per creare terminali virtuali in spazio utente . Questi includono:

• zhcon (Debian) — un terminale virtuale in spazio utente orientato alla gestione dell'I/O CJK molto meglio del sottosistema del kernel. Il suo particolare punto di forza è nella gestione delle codifiche ISO 2022 non UTF; la sua particolare debolezza sono le codifiche UTF.
• fbterm (Debian) — un terminale virtuale in spazio utente che ha generato diversi fork tra cui jfbterm. Ha un sacco di plug-in del metodo di input CJK.
• bogl-bterm (Debian) — un terminale virtuale in spazio utente che ha generato fork come niterm.
• Fbpad di Ali Gholami Rudi:un terminale virtuale minimalista per lo spazio utente che non ha dipendenze dalle librerie X.
• Il console-terminal-emulator e console-fb-realizer strumenti in nosh — un terminale virtuale in spazio utente volto a replicare i terminali virtuali del kernel Linux e FreeBSD/PC-BSD. Anch'esso non ha dipendenze dalle librerie X.
• kmscon — un terminale virtuale in spazio utente strettamente collegato al logind server in systemd e le sue nozioni di "posti a sedere".

Ali Gholami Rudi, in particolare, ha prodotto più di un semplice emulatore di terminale per il lavoro sul framebuffer. Ha anche scritto un visualizzatore PDF direct-to-framebuffer, un visualizzatore VNC, un lettore multimediale e un lettore del Corano.

Un confronto completo fianco a fianco esula dallo scopo di questa risposta; ma ecco alcuni punti rilevanti per la domanda:

• Come notato, molti dei programmi di terminale virtuale in spazio utente fanno uso delle librerie X per la gestione dei caratteri, la mappatura della tastiera, i metodi di input CJK e così via. Non sono client X, ma hanno dipendenze dalle librerie X. fbpad e gli strumenti nosh per progettazione non fanno uso di alcuna libreria X.
• I programmi che usano le librerie X per la gestione dei caratteri usano ovviamente i caratteri X. Gli altri prendono altri accordi.
  • bogl-bterm e fbpad hanno entrambi i propri formati di carattere idiosincratici. Uno converte i caratteri BDF in caratteri BOGL con bdftobogl attrezzo; e uno converte TTF nei caratteri "tinyfont" utilizzati da fbpad con lo strumento ft2tf (Arch).
  • Il nosh console-fb-realizer utilizza gli stessi font "vt" del nuovo sottosistema di terminale virtuale del kernel FreeBSD 10.1, e quindi condivide lo strumento di manipolazione dei font di FreeBSD vtfontcvt per convertire i font BDF.
• I programmi che usano le librerie X usano la mappatura della tastiera X. Per quanto riguarda gli altri:
  • Gli strumenti nosh hanno il proprio formato di mappa della tastiera idiosincratico, destinato a fornire una tastiera completa compatibile con ISO 9995-3 con l'ISO "comune" gruppo 2. Uno converte i file kbdmap BSD in questo formato con il console-convert-kbdmap attrezzo. Di nuovo, questi file kbdmap sono quelli usati con il sottosistema vt di FreeBSD/PC-BSD.
  • fbpad non esegue affatto la propria mappatura della tastiera e si basa sulla presenza del sottosistema del terminale virtuale del kernel e del suo meccanismo di mappatura della tastiera per questo.
• C'è qualche variazione nell'invocazione e nei privilegi richiesti:
  • zhcon, fbterm, bogl-bterm, fbpad e kmscon funzionano sulla base del fatto che l'emulatore di terminale genera il programma shell/login sul terminale, direttamente, come processo figlio. Hanno bisogno dei privilegi di superutente per generare login .
  • Gli strumenti nosh sono stati progettati per integrarsi con un /etc/ttys esistente (BSD), /etc/inittab (Sistema Linux 5 init ), o altro sistema, a cui lasciano il compito di generare getty/login/shell. console-fb-realizer necessita solo di privilegi sufficienti per aprire il framebuffer e i dispositivi di input degli eventi, che non devono essere privilegi di superutente, e per accedere ai FIFO e ai file ordinari gestiti da console-terminal-emulator , che a sua volta non richiede alcun privilegio speciale.

Tutti questi sono emulatori di terminale Certo. Se vuoi eliminare l'emulazione del terminale e inserire il testo nel framebuffer in modo più diretto, hai alcune scelte:

• bogl-bterm è ovviamente basato sulla Ben's Own Graphics Library di Ben Pfaff una libreria I/O framebuffer progettata per l'uso in ambienti di installazione/ripristino del sistema (e "per GUI nei PDA"). Ovviamente puoi scrivere programmi che lo usano direttamente.
• Per una via di mezzo tra la scrittura di un programma che fa uso di una libreria framebuffer per eseguire il proprio rendering e un programma che sputa sequenze di escape a quello che pensa sia un terminale:il terminale virtuale dello spazio utente nosh è modulare e si divide in pezzi componenti. Non si può semplicemente usare console-terminal-emulator .

  console-fb-realizer utilizza un file di visualizzazione con un array di celle di caratteri, come /dev/vcsa* ma un file ordinario (non un file di dispositivo speciale di caratteri) e con punti di codice Unicode, attributi ECMA-48 e colore RGB a 24 bit. Quindi si può avviarlo e scrivere semplicemente carattere+attributo+colore direttamente nel file dell'array di celle di caratteri, lasciando console-fb-realizer eseguire il rendering dei caratteri nel framebuffer.

  Per inciso:osserva che questo è l'opposto dell'integrazione con BRLTTY, che utilizza console-terminal-emulator ma non esegue console-fb-realizer .

Per utilizzare il framebuffer come console è necessario il fbdev modulo. Potrebbe essere necessario ricompilare il kernel.

Potresti anche essere interessato al progetto DirectFB, che è una libreria che semplifica l'utilizzo del framebuffer. Esistono anche applicazioni e ambienti GUI già scritti per questo.

Se riesci cat /dev/urandom > /dev/fb0 e ottieni pixel casuali sullo schermo, hai tutto ciò di cui hai bisogno.

Nel mio caso avevo bisogno di scaricare alcune informazioni di testo. L'ho testato in busybox e raspi, quindi potrebbe funzionare per te. La risposta potrebbe essere un po' lunga, poiché se non usi qualche console dovrai stampare il pixel di caratteri tu stesso. Fortunatamente qualcuno ha fatto il duro lavoro, quindi dobbiamo solo combinarlo.

In busybox o nel tuo raspi dovresti avere un fbset binario.Questo potrebbe aiutarti a scoprire le tue impostazioni come dimensioni dello schermo.

Nel mio embedded appare così:

# 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 parte importante qui è la larghezza 480 e l'altezza 272 pixel.

Come hai detto, puoi riempire lo schermo con cat /dev/urandom > /dev/fb0

e puoi cancellarlo con cat /dev/zeros > /dev/fb0

Quindi cancella lo schermo, dobbiamo assicurarti di ottenere le dimensioni correttamente.

Per caso la mia busybox aveva un binario fbsplash che riceveva in input un file .ppm.

Correggi se sbaglio, ma sembra che fb0 accetta questo formato. Dando un'occhiata a Portable Anymap su Wikipedia, ci sono diversi "sottoformati"... fbsplash ne usa uno di fantasia con il colore, e così via... ma vogliamo essere in grado di stampare solo qualcosa di leggibile. Usiamo il P1 codificato in ASCII per semplicità. Se potessimo stampare una linea verticale, sapremmo che le nostre dimensioni sono corrette. Proviamo:

Una linea verticale in un ppm di tipo P1 dovrebbe apparire così:

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

Quindi, ci saranno 272 righe, 959 caratteri di larghezza. La documentazione dice che dovrebbe essere 1 invece di f... su busybox e raspi f era più luminoso.

È importante che tu non abbia spazio dopo gli 0... Questo compito può essere un po' noioso... faresti meglio ad usare un editor di testo che ti aiuti. In vim, puoi copiare le prime due righe, andare in modalità comando ( esc), quindi digitare i seguenti caratteri:

of(esc)479a 0(esc)yy271p

Certo, sto usando le mie dimensioni, dovresti usare le tue. Cattura questo file a /dev/fb0 , dovrebbe assomigliare a:

Ok, sto barando... non c'è solo una riga lì... sono circa 8... ma quando non funziona (abbiamo dimensioni sbagliate o abbiamo spazio alla fine, avere solo una riga è molto più facile).

Se sei arrivato così lontano, dobbiamo solo stampare i pixel giusti per vederli come caratteri. Grazie a Marcel Sondaar e al suo repository su GitHub non avremo bisogno di disegnare ogni carattere.

Con una piccola modifica si espande il suo semplice programma per stampare f invece di X e 0 invece di spazi, inserisci spazi tra ogni carattere, aggiungi l'intestazione e otteniamo un file .ppm con la lettera corrispondente al suo codice carattere.

Un piccolo passo avanti e non ottieni un carattere come input, ma una riga. Cattura un file, reindirizza al tuo programma e invia l'output a /dev/fb0 e ottieni un output di testo:

Provo questa soluzione anche su un raspberry pi e ha funzionato. Il sistema mi dice che non ho la reputazione di postare più di 2 link. Finché non avrò questo, devi fare affidamento sulla mia parola :D