Como usar / dev / fb0 como um console no espaço do usuário ou enviar texto para ele

Então, eu tenho um modelo Palm Pre (P100EWW original) no qual ativei o modo de desenvolvedor e instalei um chroot Debian Squeeze. Funciona bem. Tenho planos de usar isso para QUALQUER COISA (ponto bittorrent, servidor web), mas para um telefone.

Notei que se eu fizer um, cat /dev/urandom > /dev/fb0ele realmente grava pixels aleatórios na tela até que um No space left on deviceerro seja gerado. Impressionante, agora eu posso usar a tela.

Então, que tipo de utilitários existem: A) me permite usar / dev / fb0 como um console para o qual posso enviar texto ou B) renderizar texto em / dev / fb0 na linha de comando.

Ainda não sei como recompilar o kernel para isso (eu adoraria remover completamente o WebOS e transformá-lo em um servidor ARM mínimo), para que as ferramentas de espaço do usuário, se existirem, sejam o que estou perguntando. Também prefere renderizar diretamente para / dev / fb0 e não usar X.

Para usar o framebuffer como console, você precisa do fbdevmódulo. Você pode ter que recompilar seu kernel.

Você também pode estar interessado no projeto DirectFB, que é uma biblioteca que facilita o uso do buffer de quadros. Também existem aplicativos e ambientes de GUI criados para ele.

Várias pessoas responderam às partes da sua pergunta que tratam do kernel e colocam imagens (em vez de texto) no buffer de quadros, mas até agora o restante permanece sem solução. Sim, você pode usar o subsistema de terminal virtual do kernel para criar um console chamado framebuffer . Porém, existem várias ferramentas que permitem usar o dispositivo buffer de estrutura para criar terminais virtuais no espaço do usuário . Esses incluem:

• zhcon ( Debian ) - um terminal virtual do espaço do usuário voltado para lidar com E / S CJK muito melhor do que o subsistema do kernel. Sua força particular está no manuseio de codificações ISO 2022 não UTF; sua fraqueza particular são as codificações UTF.
• fbterm ( Debian ) - um terminal virtual do espaço do usuário que gerou vários garfos, incluindo o jfbterm . Ele possui vários plug-ins de método de entrada CJK.
• bogl-bterm ( Debian ) - um terminal virtual do espaço do usuário que gerou garfos como o niterm .
• Ali Gholami Rudi fbpad - um terminal virtual userspace minimalista que não tem dependências em bibliotecas X.
• The console-terminal-emulatorand console-fb-realizertools in nosh - um terminal virtual no espaço do usuário destinado a replicar os terminais virtuais do kernel Linux e FreeBSD / PC-BSD. Também não possui dependências nas bibliotecas X.
• kmscon - um terminal virtual no espaço do usuário que está intimamente ligado ao logindservidor no systemd e suas noções de "assentos".

Ali Gholami Rudi, em particular, produziu mais do que apenas um emulador de terminal para o trabalho de buffer de quadros. Ele também escreveu um visualizador de PDF direto no framebuffer, visualizador VNC, media player e leitor de Alcorão.

Uma comparação lado a lado completa está fora do escopo desta resposta; mas aqui estão alguns pontos relevantes para a pergunta:

• Como observado, vários programas de terminal virtual no espaço do usuário utilizam bibliotecas X para manipulação de fontes, mapeamento de teclado, métodos de entrada CJK e assim por diante. Eles não são clientes X, mas possuem dependências das bibliotecas X. fbpade as ferramentas nosh por design não fazem uso de nenhuma biblioteca X.
• Os programas que usam bibliotecas X para manipulação de fontes, é claro, usam fontes X. Os outros fazem outros arranjos.
  • O bogl-bterm e o fbpad têm seus próprios formatos de fonte idiossincráticos. Um converte fontes BDF em fontes BOGL com a bdftoboglferramenta; e um converte TTF nas fontes "tinyfont" usadas pelo fbpad com a ferramenta ft2tf ( Arch ).
  • A console-fb-realizerferramenta nosh usa as mesmas fontes "vt" que o novo subsistema de terminal virtual do kernel do FreeBSD 10.1 e, portanto, compartilha a ferramenta de manipulação de fontes do FreeBSD vtfontcvtpara a conversão de fontes BDF.
• Os programas que usam bibliotecas X usam o mapeamento de teclado X. Quanto aos outros:
  • As ferramentas nosh têm seu próprio formato de mapa de teclado idiossincrático, destinado a fornecer um teclado compatível com ISO 9995-3 completo com o grupo "comum" ISO 2. Um converte arquivos kbdmap BSD para esse formato com a console-convert-kbdmapferramenta. Novamente, esses arquivos kbdmap são os usados ​​com o subsistema FreeBSD / PC-BSD vt .
  • O fbpad não faz seu próprio mapeamento de teclado e conta com a presença do subsistema de terminal virtual do kernel e seu mecanismo de mapeamento de teclado para isso.
• Há alguma variação na chamada e privilégios necessários:
  • zhcon, fbterm, bogl-bterm, fbpad e kmscon funcionam com base no fato de que o emulador de terminal gera o programa shell / login no terminal, diretamente, como um processo filho. Eles precisam de privilégios de superusuário para gerar login.
  • As ferramentas nosh foram projetadas para integrar-se a um sistema existente /etc/ttys(BSD), /etc/inittab(sistema Linux 5 init) ou outro, ao qual eles deixam o trabalho de gerar getty / login / shell. console-fb-realizerprecisa apenas de privilégios suficientes para abrir o buffer de quadros e os dispositivos de eventos de entrada, que não precisam ser privilégios de superusuário, e acessar os FIFOs e arquivos comuns mantidos por console-terminal-emulator, que, por sua vez, não precisam de privilégios especiais.

Todos estes são emuladores de terminais, é claro. Se você deseja remover a emulação de terminal e colocar o texto no buffer de moldura mais diretamente, você tem algumas opções:

• O bogl-bterm é obviamente baseado na Biblioteca Gráfica do Ben de Ben Pfaff, uma biblioteca de E / S com buffer de quadros projetada para uso em ambientes de configuração / resgate do sistema (e "para GUIs em PDAs" ). É claro que você pode escrever programas que usam isso diretamente.
• Para uma casa intermediária entre escrever um programa que faz uso de uma biblioteca buffer de quadros para fazer sua própria renderização e um programa que cospe sequências de escape para o que considera um terminal: o terminal virtual nosh do espaço do usuário é modular e se divide em peças componentes. Não se pode simplesmente usar console-terminal-emulator.

  console-fb-realizerusa um arquivo de exibição com uma matriz de células de caracteres, como /dev/vcsa*um arquivo comum (não um arquivo de dispositivo especial de caracteres) e com pontos de código Unicode, atributos ECMA-48 e cores RGB de 24 bits. Assim, é possível executá-lo e simplesmente escrever caractere + atributo + cor diretamente no arquivo da matriz de células de caracteres, deixando console-fb-realizera renderização da fonte no buffer de moldura.

  Como um aparte: Observe que isso é o oposto da integração com BRLTTY , que usa, console-terminal-emulatormas não executa console-fb-realizer.

Se você pode gato /dev/urandom > /dev/fb0e obter pixels aleatórios na tela, você tem tudo o que precisa.

No meu caso, eu precisava despejar algumas informações de texto. Eu testei isso no busybox e raspi, para que possa funcionar para você. A resposta pode demorar um pouco, pois se você não usar um console, será necessário imprimir os pixels dos caracteres. Felizmente, alguém fez o trabalho duro, por isso precisamos apenas combiná-lo.

No busybox ou no seu raspi, você deve ter um fbsetbinário. Isso pode ajudá-lo a descobrir suas configurações como dimensões da tela.

No meu incorporado fica assim:

# 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

A parte importante aqui é a largura 480 e a altura 272 pixels.

Como você mencionou, você pode preencher a tela com cat /dev/urandom > /dev/fb0

e você pode limpá-lo com cat /dev/zeros > /dev/fb0

Depois de limpar sua tela, devemos garantir que você obtenha as dimensões corretamente.

Por acaso, meu busybox tinha um binário fbsplash que recebe como entrada um arquivo .ppm.

Correto se eu estiver errado, mas parece que fb0aceita esse formato. Dando uma olhada no Portable Anymap na Wikipedia , existem vários "subformatos" ... O fbsplash usa um sofisticado com cores, e assim por diante ... mas queremos ser capazes de imprimir algo legível. Vamos usar o P1 codificado em ASCII por uma questão de simplicidade. Se pudéssemos imprimir uma linha vertical, saberíamos que nossas dimensões estão corretas. Vamos tentar:

Uma linha vertical em um tipo de ppm P1 deve ficar assim:

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

Portanto, haverá 272 linhas, 959 caracteres de largura. A documentação diz que deveria ser 1 em vez de f ... no busybox e raspi f era mais brilhante.

É importante que você não tenha espaço após o zero ... Essa tarefa pode ser um pouco entediante ... é melhor usar um editor de texto que o ajude. No vim, você pode copiar as duas primeiras linhas, vá para o modo de comando (esc) e digite os seguintes caracteres:

of(esc)479a 0(esc)yy271p

Claro, estou usando minhas dimensões, você deve usar as suas. Cat este arquivo para /dev/fb0, ele deve se parecer com:

Ok, estou trapaceando ... não é apenas uma linha lá ... é cerca de 8 ... mas quando não funciona (temos dimensões erradas ou temos espaço no final, ter apenas uma linha é muito Mais fácil).

Se você chegou até aqui, temos apenas que imprimir os pixels certos para ver como caracteres. Graças a Marcel Sondaar e seu repo no GitHub , não precisaremos desenhar cada caractere.

Com um pequeno ajuste expandir seu programa simples para imprimir fem vez de Xe0 em vez de espaços, inserir espaços entre cada char, adicionar o cabeçalho e temos um arquivo .ppm com a letra correspondente a sua charCode.

Um pequeno passo adiante e você não recebe um caractere como entrada, mas uma linha. Crie um arquivo, direcione para o seu programa e faça a saída /dev/fb0e você obtém uma saída de texto:

Eu testei esta solução também em um raspberry pi e funcionou. O sistema me diz que não tenho reputação de postar mais de 2 links. Até eu entender isso, você deve confiar na minha palavra: D

No lado do console, você pode fazer eco de itens /dev/consoleou usar o syslog e, dependendo de várias outras configurações, ele pode aparecer no console.

Para imagens, tentei colocar um arquivo bmp no fb0 e ele realmente funcionou! (sortof - várias cópias, tamanho menor)

Encontrei um programa bmp para framebuffer aqui . Esse deve ser um exemplo perfeito do formato que o fb0 está esperando. Há também fbium programa para gravar diretamente no buffer de quadros.

É um post antigo, mas normalmente entendo que você precisa do console do framebuffer (fbcon) para executar o console no framebuffer. Está na configuração. (drivers de dispositivo / gráficos / exibição do console ..)