FBInk

FBInk

FrameBuffer eInker

Sous licence GPLv3+. Hébergé ici sur GitHub.

C'est pour quoi ?

Ceci est destiné à combler le vide ressenti par les développeurs et les bricoleurs de Kobo lorsqu'ils se rendent compte qu'ils ne disposent pas d'un moyen intégré pour imprimer des éléments sur l'écran de l'appareil !
C'est particulièrement cruel lorsqu'on passe à une Kobo, après avoir été habitué à l'omniprésence des eips sur Kindle...

En bref, il imprime des messages ou des images sur votre écran, gérant le bricolage de bas niveau avec à la fois l'interface du framebuffer Linux et l'EPDC i.MX (ainsi que celui du MTK sur Kindle et celui de Sunxi sur Kobo).
Il a été testé sur Kobo, Kindle, BQ Cervantes, reMarkable et PocketBook, mais le porter sur d'autres appareils Linux, i.MX eInk devrait être trivial (bon sang, même le support de Sipix ne devrait pas être trop difficile). #64 a prouvé que nous pouvons même plier les API Sunxi à notre volonté, si vous ne vous souciez pas trop de perdre la raison dans le processus ;).

Par défaut, le rendu du texte repose sur des polices bitmap à cellules fixes groupées (voir cet article pour un petit échantillon), mais grâce aux contributions de @shermp (#20), vous pouvez également compter sur un rendu de polices TrueType/OpenType à part entière !

La prise en charge des images inclut les formats les plus courants (JPEG/PNG/TGA/BMP/GIF/PNM), ainsi que les pixels bruts dans les formats de pixels les plus pertinents (Gray8 et RGB32 ; tous deux +/- Alpha).

Il fonctionne également parfaitement sur tout type de périphérique Linux framebuffer et prend en charge une large gamme de profondeurs de bits (4bpp, 8bpp, 16bpp, 24bpp et 32bpp), vous pouvez donc l'utiliser pour dessiner sur votre fb EFI, par exemple ;) .

Comment puis-je installer ceci ?

Pour les appareils Kobo, il existe un fil de discussion ouvert ici sur MobileRead, où vous trouverez des binaires autonomes. Il manque volontairement d'instructions détaillées, car le public cible est principalement constitué de développeurs et de bricoleurs. Considérez cela comme une mesure de sécurité ;).

Il y a aussi un fil de discussion pour les appareils Kindle ici où, outre les binaires, vous trouverez également des exemples de personnes faisant des choses folles avec ;).

En pratique, la plupart des utilisateurs de Kindle et Kobo l'obtiendront gratuitement, car il est fourni avec la plupart de mes forfaits.

Comme exemple d'utilisation dans la nature, voir KFMon, où je l'utilise pour fournir un retour visuel, ou kobo-rclone, où il est également utilisé pour le grattage d'écran. Nous l'utilisons également dans KOReader, pour rendre le processus de mise à jour OTA plus convivial.
Une recherche rapide sur GitHub du code mentionnant fbink devrait également donner des résultats intéressants, par exemple, une cale de gestion des DAMAGES pour X11, un QPA Qt5 ou InkVT, un émulateur de terminal.
Voir aussi les différentes reliures dans d'autres langues, qui incluent souvent quelques exemples.

Comment puis-je le bricoler ?

Un utilitaire CLI est disponible, construit autour de la même API publique qui peut être utilisé via une bibliothèque partagée ou statique pour les projets C, ou via FFI dans d'autres langages (attention cependant, il est sous licence GPLv3+, pas LGPL). Pour l'utilitaire CLI, consultez sa documentation ou exécutez fbink --help pour plus de détails. Pour la bibliothèque, voir l'en-tête public. N'hésitez pas à me contacter si les choses ne vous paraissent pas claires !

REMARQUE : Il ne fait généralement AUCUNE tentative de gestion de la rotation des logiciels, car cela semble actuellement être la bonne chose à faire avec les versions actuelles de Kobo FW et sur Kindle.
YMMV sur un ancien FW, ou si quelque chose d'autre truque la rotation Facebook, ou si votre application implémente la rotation dans un logiciel (c'est-à-dire une fenêtre pivotée).
En ce qui concerne la rotation du matériel, il existe quelques exceptions spécifiques pour les appareils Kobo :

• Ceux fonctionnant en mode 16bpp et semblant être en mode paysage : puisque cela semble être leur état natif, nous essayons de compenser cela, car nous pouvons légitimement être utilisés avant que Nickel lui-même ne corrige cela.

• Sur les appareils dotés d'un accéléromètre, comme le Forma & Libra, où Nickel gérera lui-même la rotation du matériel.

A quoi ça ressemble ?

Quelques exemples de base du rendu de texte de cellule fixe...

Ou si nous y déposons une image...

Et avec toutes les fonctionnalités d'une transparence fonctionnelle, même sur du matériel ancien :).

Voici quelques autres polices, ainsi qu'une barre de progression...

Et lorsque vous utilisez des polices TrueType brillantes :).

Comment puis-je le construire ?

À moins que vous n'essayiez simplement de l'essayer sur un système Linux pur natif ( make linux ), vous aurez besoin d'un compilateur croisé ciblant votre périphérique cible.
Le Makefile est conçu pour détecter automatiquement mes propres configurations de ToolChain de compilation croisée, que je recommande évidemment vivement d'utiliser au lieu de m'appuyer sur des chaînes d'outils de compilation croisée génériques qui peuvent ne pas cibler exactement le bon duo noyau/libc ;).
L'utilisation de l'interface koxtoolchain devrait rendre la création de l'un d'entre eux un processus assez simple.

Si vous utilisez votre propre chaîne d'outils, veuillez noter que nous avons besoin du support C11 (GCC >= 4.9, Clang >= 3.0).

À condition que vous n'utilisiez pas un compilateur plus ancien, je vous recommande fortement de le construire avec LTO activé !

Une fois cela réglé, la cible par défaut (c'est-à-dire make ) produira une version Kobo statique, tandis que make kobo produira une version partagée supprimée et regroupera en outre tout à la manière de Kobo. Le package trouvé dans le fil de discussion Kobo est construit de cette façon.

Il existe également quelques cibles pratiques pour les types de build habituels ( make static pour une build statique, make shared pour une build partagée, make strip pour une build statique supprimée, make release pour une build partagée supprimée, make debug pour une build de débogage). comme quelques cas inhabituels pour des cas d'utilisation très spécifiques, généralement liés aux liaisons FFI ( make pic pour une construction statique PIC, ou passer STATIC_LIBM=1 pour faire une tentative de liaison statique avec libm).

Le choix de la plateforme cible se fait via une simple variable :

• Passez KINDLE=1 pour créer une version Kindle ( make kindle le fait sur une version statique supprimée).
• Passez KINDLE=1 LEGACY=1 pour créer une version Kindle FW 2.x ( make legacy fait cela sur une version statique supprimée). Cela désactive simplement CLOEXEC, qui pourrait ne pas être pris en charge sur FW 2.x.
• Passez CERVANTES=1 pour créer une version BQ/Cervantes ( make cervantes fait cela sur une version statique supprimée).
• Passez REMARKABLE=1 pour créer une version reMarkable ( make remarkable le fait sur une version statique supprimée).
• Passez POCKETBOOK=1 pour créer une version PocketBook ( make pocketbook le fait sur une version statique supprimée).

La même logique est utilisée pour permettre un peu d'adaptation :

• Passez MINIMAL=1 pour créer une version avec des fonctionnalités très limitées (pas de primitives de dessin, pas de rendu de polices à cellules fixes, pas de rendu d'image, pas de polices supplémentaires, pas d'OpenType), ce qui donne une application et une bibliothèque beaucoup plus petites.
• Passez DEBUG=1 pour créer une version de débogage et passez DEBUG=1 DEBUGFLAGS=1 pour créer une version de débogage avec CFLAGS de débogage forcé.

Vous pouvez également ajouter des fonctionnalités une par une à une version MINIMAL :

• Passez DRAW=1 pour ajouter la prise en charge des primitives de dessin.
• Passez BITMAP=1 pour ajouter la prise en charge du rendu des polices à cellules fixes. (Implique DRAW )
• Passez FONTS=1 pour ajouter la prise en charge des polices à cellules fixes supplémentaires regroupées. (Implique BITMAP )
• Passez IMAGE=1 pour ajouter la prise en charge des images. (Implique DRAW )
• Passez OPENTYPE=1 pour ajouter la prise en charge du rendu des polices OTF/TTF. (Implique DRAW )
• Passez INPUT=1 pour ajouter la prise en charge des utilitaires d'entrée.
• Passez BUTTON_SCAN=1 pour ajouter la prise en charge des éléments de numérisation de boutons spécifiques à Kobo. (Implique DRAW )

Si vous avez vraiment besoin d'une couverture Unicode extrême dans le chemin de code à cellules fixes, vous pouvez également choisir d'intégrer GNU Unifont, en passant UNIFONT=1 .
Soyez averti que cela ajoutera près de 2 Mo à la taille binaire et que la police est en fait divisée en deux (les glyphes double largeur sont envoyés à une police spécifique), ce qui peut diminuer son utilité dans la pratique...
Pour des raisons évidentes, ceci n'est jamais activé par défaut.
Sauf si vous faites des choses très spécifiques, vous souhaitez généralement qu'au moins DRAW et BITMAP soient activés dans une version MINIMAL ...

N'oubliez pas d'exécuter au moins un make cleanlib lors du changement de plate-forme cible ou d'indicateurs de fonctionnalités, sinon la dernière version de la bibliothèque correspondante sera conservée, car elle remplira les dépendances de make ;).

En cours de route, quelques outils auxiliaires peuvent apparaître dans le dossier utils . make utils en fera une construction statique (ce qui est la manière recommandée de le faire, car ils s'appuient assez grossièrement sur l'API interne de FBInk). Actuellement, il s’agit d’un outil de diagnostic concernant le comportement de rotation et du test de résistance catastrophique mentionné ci-dessous.
La plupart d'entre eux n'ont été testés que sur Kobo et devraient probablement être laissés de côté à moins que vous ne sachiez ce que vous faites ;).

Un outil permettant de manipuler correctement la profondeur de bits sur les appareils eInk est également disponible et peut être construit pour les cibles e-Ink avec make fbdepth .
Son nom peu inspiré est fbdepth , et il est utilisé par KOReader sur Kobo & reMarkable pour imposer une rotation saine et passer à une profondeur de bits plus efficace. Il a également été testé sur Kindle, où la gestion de la rotation devrait au moins se comporter correctement. Notez que sur FW 5.x, l'interface graphique d'origine fonctionne sous X, et X n'aimera pas que vous fassiez tourner le fb sous ses pieds ;).
Si vous voulez le plus petit binaire possible, assurez-vous de le construire seul, à partir d'une arborescence source vierge.

Il existe également un exemple assez stupide présentant l'API dump/restore qui peut être construite via make dump .
Une autre démo stupide basée sur l'effet de feu PSX Doom a été implémentée, pour tester l'EPDC d'une manière légèrement intéressante.

Si jamais vous étiez curieux de connaître toute la fête de mxcfb alt_buffer, vous pouvez jeter un œil à ce PoC.

Dans la même veine, si vous recherchez des manigances de rotation et de saisie sur Kobo, make devcap construira une archive tar contenant quelques binaires et un script devcap_test.sh qui, une fois exécuté sur le périphérique cible, compilera un peu de infos. En particulier, si jamais vous avez besoin de signaler un bug contre fbdepth , je vous demanderai probablement de l'exécuter et de joindre les résultats au problème ;).

Et au sujet de l'entrée et de la rotation sur Kobo, make ftrace construira un simple utilitaire de suivi de pointeur, qui exploite libevdev et quelques-uns de nos appels API les plus funky pour essayer de donner un sens aux manigances de traduction d'entrée qui se produisent sur Kobo.
Si vous avez l'intention de gérer la saisie tactile de quelque manière que ce soit dans votre code, cela devrait être un bon endroit où chercher ;).
Il montre également comment gérer efficacement la saisie au stylet et le dessin sur Elipsa.

Quant à make input_scan , il construira un petit outil CLI autour de l'API fbink_input_scan , qui permet de comprendre quel périphérique d'entrée fait quoi (c'est-à-dire "où est ce foutu écran tactile ?" ;)).

REMARQUES

La prise en charge Kindle couvre toute la gamme Kindle, à partir du K2.

La prise en charge de Kobo couvre toute la gamme Kobo, à partir du Kobo Touch A/B/C (REMARQUE : certaines fonctionnalités ne sont pas disponibles sur les SoC sunxi, cf, documentation API).

Le support de BQ Cervantes a été apporté par @pazos (#17) et devrait gérer la programmation actuelle.

Un support remarquable a été contribué par @tcrs (#41) et prend en charge le rM2 lorsqu'il est associé à l'une des différentes implémentations de cale rm2fb.

La prise en charge de PocketBook a été testée par @ezdiy (#47) et devrait prendre en charge le même ensemble d'appareils que KOReader. Gardez à l'esprit que PocketBook est une plateforme... compliquée à gérer, et que je n'y ai pas accès moi-même. Cela signifie qu'il y a pas mal de bizarreries impliquées :

• Nous n'utilisons pas InkView pour dessiner, ce qui signifie, entre autres bizarreries, que le rendu des couleurs n'est pas pris en charge sur les appareils couleur et que le mappage du mode de forme d'onde peut être incertain, en particulier sur les appareils fonctionnant sur un SoC AW (nous utilisons toujours l'API du noyau mxcfb , et sur ces appareils, c'est une cale très, très, très originale. Attendez-vous à des bugs étranges et étranges, surtout si vous commencez à jouer avec la rotation matérielle de Facebook).
• Une autre bizarrerie particulièrement répandue sur les appareils AW est que les deux structures fbinfo sont complètement fausses. FBInk les transformera de manière heuristique lors de l'initialisation, donc si vous avez besoin d'y accéder, passez toujours par fbink_get_fb_info au lieu de recourir vous-même aux ioctls natifs.
• En parlant d'InkView, par défaut, il est ouvert lors de l'initialisation pour faciliter l'identification du périphérique. Cela peut être problématique, car InkView extrait une crapton métrique d'anciennes bibliothèques via DT_NEEDED... et initialise certaines d'entre elles au chargement, ce qui est une recette parfaite pour un désastre si vous utilisez vous-même ces mêmes bibliothèques, surtout si vous J'en utilise différentes versions. Afin d'éviter ce gâchis, vous pouvez demander à FBInk de ne jamais toucher à InkView, en définissant la variable FBINK_NO_INKVIEW dans votre environnement. Actuellement, le seul inconvénient sera une identification altérée de l'appareil : en particulier, aucun nom d'appareil et un DPI inexact (nous utiliserons par défaut 212, sauf si vous définissez un remplacement via la variable d'environnement FBINK_FORCE_DPI )).
• Et en ce qui concerne la rotation, par défaut, si l'appareil semble avoir une orientation native en mode paysage (ce qui s'avère être le cas sur la plupart des modèles), FBInk applique une rotation logicielle afin d'imprimer des éléments en mode Portrait (principalement). pour faciliter l'interopérabilité avec KOReader). Vous pouvez désactiver ce comportement en définissant la variable FBINK_NO_SW_ROTA dans votre environnement, auquel cas nous dessinerons toujours la disposition fb native.

Projets associés

Si, au lieu d'écrire dans le framebuffer, vous souhaitez en récupérer un instantané PNG (ce qui peut s'avérer utile), j'ai une version fortement modifiée de FBGrab qui devrait gérer correctement les différentes bizarreries des framebuffers eInk ;). Si vous n'avez pas réellement besoin d'un fichier PNG et que vous souhaitez simplement jouer avec les dumps fb en mémoire, examinez l'ensemble des appels API fbink_dump et fbink_restore .

Reliures dans d'autres langues

Pour que tout le monde puisse s'amuser, même si vous ne supportez pas le C !

Rouiller:

• fbink-sys par @Szybet (liaisons Bare bindgen)
• fbink-rs par @sublipri (liaisons Bare bindgen, certains wrappers sûrs, dépendants du cross)

Go : go-fbink et son successeur go-fbink-v2 par @shermp

LuaJIT : lua-fbink par @NiLuJe

Python : py-fbink par @NiLuJe

Notez que comme l'API peut ne pas être entièrement stable sur master, celles-ci sont toutes liées à une balise spécifique (généralement la dernière version). Vous devriez honorer cette exigence, sinon l'enfer se déchaînera ;).
J'essaie généralement de minimiser les casses, ou à défaut, de rendre les chemins de mise à niveau aussi indolores que possible, mais voilà, prendre en charge de nouveaux éléments signifie souvent que les éléments existants doivent fonctionner légèrement différemment.

J'essaie de détailler les ruptures API/ABI dans les commentaires de chaque balise, mais un bon moyen de visualiser cela est bien sûr de comparer l'en-tête public unique (ou, pour un aperçu rapide sans contexte, les en-têtes minimaux générés pour les liaisons FFI) ;).