FBInk

FBInk

FrameBuffer eInker

Licenciado sob a GPLv3+. Hospedado aqui no GitHub.

Para que serve?

O objetivo é preencher a lacuna sentida pelos desenvolvedores e criadores da Kobo quando percebem que não possuem uma maneira integrada de imprimir coisas na tela do dispositivo!
É especialmente cruel quando se muda para um Kobo, depois de estar acostumado com a onipresença dos eips no Kindle...

Resumindo, ele imprime mensagens ou imagens em sua tela, lidando com ajustes de baixo nível tanto na interface framebuffer do Linux quanto no i.MX EPDC (bem como no MTK no Kindle e no sunxi no Kobo).
Ele foi testado em Kobo, Kindle, BQ Cervantes, reMarkable e PocketBook, mas portá-lo para outros dispositivos Linux, i.MX eInk, deve ser trivial (inferno, mesmo o suporte ao Sipix não deve ser muito difícil). # 64 provou que podemos até mesmo dobrar as APIs sunxi à nossa vontade, se você não se importar muito em perder a sanidade no processo;).

Por padrão, a renderização de texto depende de fontes de bitmap de células fixas agrupadas (veja esta postagem para uma pequena amostra), mas graças às contribuições de @shermp (# 20), você também pode contar com a renderização completa de fontes TrueType/OpenType!

O suporte de imagem inclui os formatos mais comuns (JPEG/PNG/TGA/BMP/GIF/PNM), bem como pixels compactados brutos nos formatos de pixel mais relevantes (Gray8 e RGB32; ambos +/- Alpha).

Ele também funciona perfeitamente em qualquer tipo de dispositivo framebuffer Linux e suporta uma ampla variedade de profundidades de bits (4bpp, 8bpp, 16bpp, 24bpp e 32bpp), então você pode usar isso para desenhar em seu EFI fb, por exemplo;) .

Como faço para instalar isso?

Para dispositivos Kobo, há um tópico de discussão aberto aqui no MobileRead, onde você encontrará binários independentes. Faltam propositalmente instruções detalhadas, porque o público-alvo são principalmente desenvolvedores e criadores. Pense nisso como uma precaução de segurança;).

Há também um tópico irmão para dispositivos Kindle aqui onde, além de binários, você também encontrará exemplos de pessoas fazendo coisas malucas com ele ;).

Na prática, a maioria dos usuários do Kindle e Kobo o obterá gratuitamente, pois ele vem com a maioria dos meus pacotes.

Como exemplo de uso em estado selvagem, veja KFMon, onde estou usando-o para fornecer feedback visual, ou kobo-rclone, onde também é usado para captura de tela. Também o estamos usando no KOReader, para tornar o processo de atualização OTA mais fácil de usar.
Uma rápida pesquisa no GitHub por código mencionando fbink também deve produzir resultados interessantes, por exemplo, um calço de tratamento de DAMAGE para X11, um QPA Qt5 ou InkVT, um emulador de terminal.
Veja também as diversas ligações em outras linguagens, que geralmente incluem alguns exemplos.

Como posso mexer nisso?

Um utilitário CLI está disponível, construído em torno da mesma API pública que pode ser usada por meio de uma biblioteca compartilhada ou estática para projetos C, ou via FFI em outras linguagens (cuidado, porém, ele é licenciado sob a GPLv3+, não a LGPL). Para o utilitário CLI, consulte sua documentação ou execute fbink --help para obter detalhes. Para a biblioteca, consulte o cabeçalho público. Não hesite em entrar em contato comigo se as coisas não parecerem claras!

NOTA: Geralmente NÃO faz nenhuma tentativa de lidar com a rotação de software, porque atualmente parece ser a coisa certa a fazer com as versões atuais do Kobo FW e no Kindle.
YMMV em FW mais antigo, ou se alguma outra coisa estiver falsificando a rotação do fb, ou se seu aplicativo estiver implementando a rotação no software (ou seja, uma janela de visualização girada).
No que diz respeito à rotação de hardware, existem algumas exceções específicas feitas para dispositivos Kobo:

• Aqueles rodando no modo 16bpp e parecendo estar no modo paisagem: como esse parece ser seu estado nativo, tentamos compensar isso, pois podemos ser legitimamente usados ​​antes que o próprio Nickel corrija isso.

• Em aparelhos com acelerômetro, como o Forma & Libra, onde o próprio Níquel fará a rotação do hardware.

Como parece?

Alguns exemplos básicos de renderização de texto em células fixas...

Ou se colocarmos uma imagem lá...

E com todos os recursos de transparência de trabalho, mesmo em hardware antigo :).

Aqui estão algumas outras fontes, bem como uma barra de progresso...

E ao usar fontes TrueType brilhantes :).

Como faço para construí-lo?

A menos que você esteja apenas tentando dar uma volta em um sistema Linux nativo puro ( make linux ), você precisará de um compilador cruzado direcionado ao seu, bem, dispositivo de destino.
O Makefile é adaptado para detectar automaticamente minhas próprias configurações de ToolChain de compilação cruzada, que eu evidentemente recomendo usar em vez de confiar em cadeias de ferramentas genéricas de compilação cruzada que podem não ter como alvo exatamente a dupla kernel/libc correta;).
Usar o frontend koxtoolchain deve tornar a construção de um desses um processo bastante simples.

Caso você esteja usando seu próprio conjunto de ferramentas, observe que precisamos de suporte C11 (GCC >= 4.9, Clang >= 3.0).

Desde que você não esteja usando um compilador mais antigo, recomendo fortemente construí-lo com LTO habilitado!

Com isso resolvido, o destino padrão (ou seja, make ) produzirá uma compilação estática do Kobo, enquanto make kobo produzirá uma compilação compartilhada despojada e, adicionalmente, empacotará tudo do jeito Kobo. O pacote encontrado no tópico Kobo é construído desta forma.

Existem alguns alvos de conveniência para tipos de compilação comuns ( make static para uma compilação estática, make shared para uma compilação compartilhada, make strip para uma compilação estática despojada, make release para uma compilação compartilhada despojada, make debug para uma compilação de depuração), também como alguns incomuns para casos de uso muito específicos, geralmente relacionados a ligações FFI ( make pic para uma construção estática do PIC ou passando STATIC_LIBM=1 para make para tentar vincular estaticamente ao libm).

A escolha da plataforma alvo é feita através de uma variável simples:

• Passe KINDLE=1 para criar uma compilação do Kindle ( make kindle faz isso em uma compilação estática despojada).
• Passe KINDLE=1 LEGACY=1 para fazer uma compilação FW 2.x do Kindle ( make legacy faz isso em uma compilação estática despojada). Isso basicamente desativa o CLOEXEC, que pode não ser compatível com FW 2.x.
• Passe CERVANTES=1 para criar uma compilação BQ/Cervantes ( make cervantes faz isso em uma compilação estática despojada).
• Passe REMARKABLE=1 para criar uma compilação reMarkable ( make remarkable faz isso em uma compilação estática despojada).
• Passe POCKETBOOK=1 para criar uma compilação do PocketBook ( make pocketbook faz isso em uma compilação estática despojada).

A mesma lógica é usada para permitir um pouco de adaptação:

• Passe MINIMAL=1 para criar uma compilação com funcionalidade muito limitada (sem primitivas de desenho, sem renderização de fonte de célula fixa, sem renderização de imagem, sem fontes extras, sem OpenType), o que gera um aplicativo e uma biblioteca muito menores.
• Passe DEBUG=1 para criar uma compilação de depuração e passe DEBUG=1 DEBUGFLAGS=1 para criar uma compilação de depuração com CFLAGS de depuração imposta.

Você também pode anexar recursos um por um a uma compilação MINIMAL :

• Passe DRAW=1 para adicionar suporte para desenho de primitivas.
• Passe BITMAP=1 para adicionar suporte para renderização de fonte de célula fixa. (Implica DRAW )
• Passe FONTS=1 para adicionar suporte para fontes extras de célula fixa agrupadas. (Implica BITMAP )
• Passe IMAGE=1 para adicionar suporte de imagem. (Implica DRAW )
• Passe OPENTYPE=1 para adicionar suporte de renderização de fonte OTF/TTF. (Implica DRAW )
• Passe INPUT=1 para adicionar suporte para utilitários de entrada.
• Passe BUTTON_SCAN=1 para adicionar suporte para o material de digitalização de botões específico da Kobo. (Implica DRAW )

Se você realmente precisa de cobertura Unicode extrema no codepath de célula fixa, você também pode optar por incorporar o GNU Unifont, passando UNIFONT=1 .
Esteja avisado que isso adicionará quase 2 MB ao tamanho binário e que a fonte será dividida em duas (os glifos de largura dupla são atribuídos a uma fonte específica), o que pode prejudicar sua utilidade na prática...
Por razões óbvias, isso nunca é habilitado por padrão.
A menos que você esteja fazendo coisas muito específicas, geralmente deseja pelo menos DRAW & BITMAP habilitados em uma compilação MINIMAL ...

Não se esqueça de executar pelo menos um make cleanlib ao alterar plataformas de destino ou sinalizadores de recursos, caso contrário, a última compilação da biblioteca correspondente será mantida, porque preencherá as dependências do make;).

Ao longo do caminho, algumas ferramentas auxiliares podem surgir na pasta utils . make utils fará uma construção estática deles (que é a maneira recomendada de fazer isso, já que eles pegam carona na API interna do FBInk). Atualmente, estes consistem em uma ferramenta de diagnóstico do comportamento de rotação e no teste de estresse de destruição mencionado abaixo.
A maioria deles foi testada apenas na Kobo e provavelmente deve ser deixada de lado, a menos que você saiba o que está fazendo;).

Uma ferramenta para manipular adequadamente a profundidade de bits em dispositivos eInk também está disponível e pode ser construída para alvos e-Ink com make fbdepth .
Seu nome pouco inspirado é fbdepth e é usado pelo KOReader no Kobo e reMarkable para impor uma rotação sensata e mudar para uma profundidade de bits mais eficiente. Também foi testado no Kindle, onde o manuseio da rotação, no mínimo, deveria estar se comportando corretamente. Observe que no FW 5.x, a GUI padrão é executada no X, e o X não gostará que você gire o fb sob seus pés;).
Se você deseja o menor binário possível, certifique-se de construí-lo sozinho, a partir de uma árvore de origem original.

Há também um exemplo bastante estúpido mostrando a API dump/restore que pode ser construída via make dump .
Outra demo estúpida baseada no efeito de fogo do PSX Doom foi implementada, para testar o EPDC de uma maneira levemente interessante.

Se você já ficou curioso sobre toda a festa do mxcfb alt_buffer, pode dar uma olhada neste PoC.

Na mesma linha, se você estiver procurando por travessuras de rotação e entrada no Kobo, make devcap irá construir um tarball contendo alguns binários e um script devcap_test.sh, que, quando executado no dispositivo de destino, irá compilar um pouco de informações. Em particular, se você precisar relatar um bug em fbdepth , provavelmente pedirei que você execute isso e anexe os resultados ao problema;).

E no que diz respeito à entrada e rotação no Kobo, make ftrace criará um utilitário simples de trilha de ponteiro, que aproveita o libevdev e algumas de nossas chamadas de API mais divertidas para tentar entender as travessuras de tradução de entrada que acontecem no Kobo.
Se você pretende manipular a entrada por toque de alguma forma em seu código, este deve ser um bom lugar para procurar;).
Ele também demonstra como lidar de forma eficaz com a entrada e o desenho da caneta na Elipsa.

Quanto make input_scan , ele criará uma pequena ferramenta CLI em torno da API fbink_input_scan , que ajuda a entender qual dispositivo de entrada faz o quê (também conhecido como "onde está aquela maldita tela sensível ao toque?" ;)).

NOTAS

O suporte do Kindle cobre toda a linha Kindle, começando pelo K2.

O suporte Kobo cobre toda a linha Kobo, começando pelo Kobo Touch A/B/C (NOTA: alguns recursos não estão disponíveis em SoCs sunxi, cf, documentos API).

O apoio do BQ Cervantes foi contribuído por @pazos (#17) e deve cuidar da escalação atual.

O suporte notável foi contribuído por @tcrs (#41) e suporta o rM2 quando emparelhado com uma das várias implementações de shim rm2fb.

O suporte ao PocketBook foi testado por @ezdiy (#47) e deve suportar o mesmo conjunto de dispositivos que o KOReader. Tenha em mente que o PocketBook é uma plataforma complicada de se lidar e que eu mesmo não tenho acesso a ela. O que significa que existem algumas peculiaridades envolvidas:

• Não usamos o InkView para desenhar, o que significa, entre outras peculiaridades, que a renderização de cores não é suportada em dispositivos coloridos e que o mapeamento do modo de forma de onda pode ser duvidoso, especialmente em dispositivos executados em um SoC AW (sempre usamos a API do kernel mxcfb , e nesses dispositivos, é um calço muito, muito, muito peculiar. Espere bugs estranhos e estranhos, especialmente se você começar a brincar com a rotação do hardware fb).
• Outra peculiaridade especialmente prevalente nos dispositivos AW é que as duas estruturas fbinfo são completamente falsas. O FBInk irá transformá-los heuristicamente em forma no init, então se acontecer de você precisar acessá-los, sempre passe por fbink_get_fb_info em vez de recorrer aos ioctls nativos você mesmo.
• Falando em InkView, por padrão, ele é aberto no init para ajudar na identificação do dispositivo. Isso pode ser problemático, porque o InkView extrai um monte de métricas de bibliotecas antigas via DT_NEEDED... e inicializa algumas delas durante o carregamento, o que é uma receita perfeita para o desastre se você mesmo usar essas mesmas bibliotecas, especialmente se você estamos usando versões diferentes deles. Para evitar essa bagunça, você pode pedir ao FBInk para nunca tocar no InkView, definindo a variável FBINK_NO_INKVIEW em seu ambiente. Atualmente, a única desvantagem será a identificação prejudicada do dispositivo: especificamente, nenhum nome de dispositivo e DPI impreciso (o padrão será 212, a menos que você defina uma substituição por meio da variável env FBINK_FORCE_DPI )).
• E no que diz respeito à rotação, por padrão, se o dispositivo parecer que sua orientação nativa é paisagem (o que é verdade na maior parte da programação), o FBInk impõe uma rotação de software para realmente imprimir coisas em Retrato (principalmente para ajudar na interoperabilidade com o KOReader). Você pode desabilitar esse comportamento definindo a variável FBINK_NO_SW_ROTA em seu ambiente, nesse caso sempre desenharemos no layout nativo do fb.

Projetos relacionados

Se, em vez de escrever no framebuffer, você quiser obter um instantâneo PNG dele (o que pode ser útil), eu tenho uma versão fortemente modificada do FBGrab que deve lidar com as várias peculiaridades dos framebuffers eInk;). Se você realmente não precisa de um arquivo PNG e apenas deseja brincar com dumps fb na memória, dê uma olhada em todas as chamadas de API fbink_dump e fbink_restore .

Vinculações em outros idiomas

Para que todos possam se divertir, mesmo que você não aguente C!

Ferrugem:

• fbink-sys por @Szybet (ligações bare bindgen)
• fbink-rs por @sublipri (ligações bare bindgen, alguns wrappers seguros, dependentes de cross)

Go: go-fbink e seu sucessor go-fbink-v2 por @shermp

LuaJIT: lua-fbink por @NiLuJe

Python: py-fbink por @NiLuJe

Observe que, como a API pode não ser totalmente estável no master, tudo isso está vinculado a uma tag específica (geralmente, a versão mais recente). Você deve honrar esse requisito, ou o inferno irá explodir;).
Eu geralmente tento manter as quebras ao mínimo ou, salvo isso, tornar os caminhos de atualização o mais simples possível, mas, aí está, oferecer suporte a coisas novas geralmente significa que as coisas existentes têm que funcionar de maneira um pouco diferente.

Tento detalhar as quebras de API/ABI nos comentários de cada tag, mas uma boa maneira de visualizar isso é diferenciar o cabeçalho público único (ou, para uma visão geral rápida e sem contexto, os cabeçalhos mínimos gerados para ligações FFI);).