FBInk

FBInk

FrameBuffer eInker

Lizenziert unter der GPLv3+. Hier auf GitHub untergebracht.

Wozu dient es?

Dies soll die Lücke füllen, die Kobo-Entwickler und -Tüftler verspüren, wenn sie feststellen, dass sie keine integrierte Möglichkeit haben, Dinge auf dem Bildschirm des Geräts zu drucken!
Besonders grausam ist es, wenn man zu einem Kobo wechselt, nachdem man sich an die Allgegenwärtigkeit von eips auf dem Kindle gewöhnt hat ...

Kurz gesagt, es druckt Nachrichten oder Bilder auf Ihrem Bildschirm und übernimmt dabei die einfachen Basteleien sowohl mit der Linux-Framebuffer-Schnittstelle als auch mit dem i.MX EPDC (sowie dem MTK auf Kindle und dem Sunxi auf Kobo).
Es wurde auf Kobo, Kindle, BQ Cervantes, reMarkable und PocketBook getestet, aber die Portierung auf andere Linux- und i.MX-eInk-Geräte sollte trivial sein (verdammt, selbst die Sipix-Unterstützung sollte nicht allzu schwierig sein). #64 hat bewiesen, dass wir Sunxi-APIs sogar unserem Willen unterwerfen können, wenn Ihnen der Verlust Ihres Verstandes dabei egal ist ;).

Standardmäßig basiert die Textwiedergabe auf gebündelten Bitmap-Schriftarten mit festen Zellen (eine kleine Auswahl finden Sie in diesem Beitrag). Dank der Beiträge von @shermp (#20) können Sie sich jedoch auch auf die vollständige Wiedergabe von TrueType/OpenType-Schriftarten verlassen!

Die Bildunterstützung umfasst die gängigsten Formate (JPEG/PNG/TGA/BMP/GIF/PNM) sowie rohe gepackte Pixel in den relevantesten Pixelformaten (Gray8 und RGB32; beide +/- Alpha).

Es funktioniert auch einwandfrei auf jeder Art von Linux-Framebuffer-Gerät und unterstützt eine Vielzahl von Bittiefen (4bpp, 8bpp, 16bpp, 24bpp und 32bpp), sodass Sie es beispielsweise zum Zeichnen auf Ihrer EFI-FB verwenden können ;) .

Wie installiere ich das?

Für Kobo-Geräte gibt es hier auf MobileRead einen Diskussionsthread, in dem Sie zufällig eigenständige Binärdateien finden. Auf detaillierte Anleitungen wird bewusst verzichtet, da die Zielgruppe vor allem Entwickler und Tüftler sind. Betrachten Sie dies als Sicherheitsmaßnahme ;).

Es gibt hier auch einen Schwesterthread für Kindle-Geräte, in dem Sie neben Binärdateien auch Beispiele von Leuten finden, die verrückte Dinge damit machen ;).

In der Praxis erhalten die meisten Kindle- und Kobo-Benutzer es tatsächlich kostenlos, da es in den meisten meiner Pakete enthalten ist.

Als Beispiel für die Verwendung in freier Wildbahn siehe KFMon, wo ich es verwende, um visuelles Feedback zu geben, oder kobo-rclone, wo es auch für Screen Scraping verwendet wird. Wir verwenden es auch in KOReader, um den OTA-Update-Prozess benutzerfreundlicher zu gestalten.
Eine schnelle GitHub-Suche nach Code, in dem fbink erwähnt wird, sollte ebenfalls interessante Ergebnisse liefern, z. B. einen DAMAGE-Handling-Shim für X11, einen Qt5-QPA oder InkVT, einen Terminalemulator.
Siehe auch die verschiedenen Bindungen in anderen Sprachen, die oft einige Beispiele enthalten.

Wie kann ich daran herumbasteln?

Es ist ein CLI-Dienstprogramm verfügbar, das auf derselben öffentlichen API basiert und über eine gemeinsam genutzte oder statische Bibliothek für C-Projekte oder über FFI in anderen Sprachen verwendet werden kann (Achtung: Es ist unter der GPLv3+ und nicht unter der LGPL lizenziert). Weitere Informationen zum CLI-Dienstprogramm finden Sie in der zugehörigen Dokumentation oder führen Sie fbink --help aus. Informationen zur Bibliothek finden Sie im öffentlichen Header. Zögern Sie nicht, mich zu kontaktieren, wenn Ihnen etwas unklar erscheint!

HINWEIS: Es wird im Allgemeinen KEIN Versuch unternommen, die Softwarerotation zu handhaben, da dies derzeit sowohl für aktuelle Kobo FW-Versionen als auch für Kindle die richtige Vorgehensweise zu sein scheint.
YMMV auf älterer FW oder wenn etwas anderes mit der fb-Rotation herumspielt oder wenn Ihre Anwendung die Rotation in der Software implementiert (z. B. ein gedrehtes Ansichtsfenster).
Was die Hardware-Rotation betrifft, gibt es für Kobo-Geräte einige spezifische Ausnahmen:

• Diejenigen, die im 16bpp-Modus laufen und im Querformat zu sein scheinen: Da dies ihr ursprünglicher Zustand zu sein scheint, versuchen wir, dies zu kompensieren, da wir rechtmäßig verwendet werden können, bevor Nickel selbst dies korrigiert.

• Bei Geräten mit Beschleunigungsmesser, wie dem Forma und der Libra, bei denen Nickel selbst die Hardware-Rotation übernimmt.

Wie sieht es aus?

Ein paar grundlegende Beispiele für die Darstellung von Text in festen Zellen ...

Oder wenn wir dort ein Bild einfügen ...

Und mit allem Drum und Dran der Arbeitstransparenz, selbst auf alter Hardware :).

Hier sind ein paar andere Schriftarten sowie ein Fortschrittsbalken ...

Und wenn glänzende TrueType-Schriftarten verwendet werden :).

Wie baue ich es?

Sofern Sie nicht gerade versuchen, es auf einem nativen, reinen Linux-System ( make linux ) auszuprobieren, benötigen Sie einen Cross-Compiler, der auf Ihr Zielgerät abzielt.
Das Makefile ist so zugeschnitten, dass es automatisch meine eigenen Cross-Compilation-ToolChain-Setups erkennt, deren Verwendung ich natürlich wärmstens empfehle, anstatt sich auf generische Cross-Compilation-Toolchains zu verlassen, die möglicherweise nicht genau auf das richtige Kernel/Libc-Duo abzielen ;).
Die Verwendung des Koxtoolchain-Frontends sollte die Erstellung eines dieser Elemente zu einem ziemlich schmerzlosen Prozess machen.

Falls Sie Ihre eigene Toolchain verwenden, beachten Sie bitte, dass wir C11-Unterstützung benötigen (GCC >= 4.9, Clang >= 3.0).

Vorausgesetzt, Sie verwenden keinen älteren Compiler, empfehle ich dringend, dies mit aktiviertem LTO zu erstellen!

Wenn das erledigt ist, ergibt das Standardziel (also make ) einen statischen Kobo-Build, während make kobo einen abgespeckten gemeinsamen Build ergibt und zusätzlich alles auf die Kobo-Art verpackt. Das im Kobo-Thread gefundene Paket ist auf diese Weise erstellt.

Es gibt auch ein paar praktische Ziele für übliche Build-Typen ( make static für einen statischen Build, make shared für einen gemeinsam genutzten Build, make strip für einen entfernten statischen Build, make release für einen entfernten gemeinsam genutzten Build, make debug für einen Debug-Build). als einige ungewöhnliche für sehr spezifische Anwendungsfälle, die normalerweise mit FFI-Bindungen zusammenhängen ( make pic für einen statischen PIC-Build oder die Übergabe STATIC_LIBM=1 an make, um zu versuchen, eine statische Verknüpfung mit libm herzustellen).

Die Wahl der Zielplattform erfolgt über eine einfache Variable:

• Übergeben Sie KINDLE=1 um einen Kindle-Build zu erstellen ( make kindle führt dies bei einem abgespeckten statischen Build aus).
• Übergeben Sie KINDLE=1 LEGACY=1 , um einen Kindle-Build mit FW 2.x zu erstellen ( make legacy erledigt dies für einen abgespeckten statischen Build). Dadurch wird im Grunde nur CLOEXEC deaktiviert, das auf FW 2.x möglicherweise nicht unterstützt wird.
• Übergeben Sie CERVANTES=1 , um einen BQ/Cervantes-Build zu erstellen ( make cervantes führt dies bei einem gestrippten statischen Build aus).
• Übergeben Sie REMARKABLE=1 um einen reMarkable-Build zu erstellen ( make remarkable macht das bei einem gestrippten statischen Build).
• Übergeben Sie POCKETBOOK=1 um einen PocketBook-Build zu erstellen ( make pocketbook führt dies bei einem abgespeckten statischen Build aus).

Die gleiche Logik wird verwendet, um ein wenig Anpassung zu ermöglichen:

• Übergeben Sie MINIMAL=1 , um einen Build mit sehr eingeschränkter Funktionalität zu erstellen (keine Zeichnungsprimitive, kein Rendern von Schriftarten mit festen Zellen, kein Rendern von Bildern, keine zusätzlichen Schriftarten, kein OpenType), was zu einer viel kleineren Anwendung und Bibliothek führt.
• Übergeben Sie DEBUG=1 , um einen Debug-Build zu erstellen, und übergeben Sie DEBUG=1 DEBUGFLAGS=1 um einen Debug-Build mit erzwungenen Debug-CFLAGS zu erstellen.

Sie können Funktionen auch einzeln an einen MINIMAL -Build anhängen :

• Übergeben Sie DRAW=1 um Unterstützung für das Zeichnen von Grundelementen hinzuzufügen.
• Übergeben Sie BITMAP=1 um Unterstützung für die Darstellung von Schriftarten mit festen Zellen hinzuzufügen. (Impliziert DRAW )
• Übergeben Sie FONTS=1 um Unterstützung für die zusätzlich gebündelten Schriftarten mit festen Zellen hinzuzufügen. (Impliziert BITMAP )
• Übergeben Sie IMAGE=1 um Bildunterstützung hinzuzufügen. (Impliziert DRAW )
• Übergeben Sie OPENTYPE=1 um Unterstützung für die Wiedergabe von OTF/TTF-Schriftarten hinzuzufügen. (Impliziert DRAW )
• Übergeben Sie INPUT=1 um Unterstützung für Eingabedienstprogramme hinzuzufügen.
• Übergeben Sie BUTTON_SCAN=1 um Unterstützung für den Kobo-spezifischen Button-Scan hinzuzufügen. (Impliziert DRAW )

Wenn Sie wirklich eine extreme Unicode-Abdeckung im Codepfad für feste Zellen benötigen, können Sie auch GNU Unifont einbetten, indem Sie UNIFONT=1 übergeben.
Seien Sie gewarnt, dass dies die Binärgröße um fast 2 MB erhöht und dass die Schriftart tatsächlich in zwei Teile geteilt ist (Glyphen mit doppelter Breite werden auf eine bestimmte Schriftart umgestellt), was ihren Nutzen in der Praxis beeinträchtigen könnte ...
Aus offensichtlichen Gründen ist dies nie standardmäßig aktiviert.
Sofern Sie nicht ganz bestimmte Dinge tun, möchten Sie im Allgemeinen, dass DRAW & BITMAP in einem MINIMAL -Build aktiviert ist ...

Vergessen Sie nicht, mindestens eine make cleanlib auszuführen, wenn Sie Zielplattformen oder Feature-Flags ändern, da sonst der neueste passende Bibliotheksbuild beibehalten wird, da er die Make-Abhängigkeiten erfüllt ;).

Unterwegs tauchen möglicherweise einige Hilfstools im Ordner utils auf. make utils erstellen einen statischen Build davon (was die empfohlene Vorgehensweise ist, da sie eher grob auf die interne API von FBInk zurückgreifen). Derzeit bestehen diese aus einem Diagnosetool zum Rotationsverhalten und dem unten erwähnten Doom-Stresstest.
Die meisten davon wurden nur auf Kobo getestet und sollten wahrscheinlich in Ruhe gelassen werden, es sei denn, Sie wissen, was Sie tun ;).

Ein Tool zum ordnungsgemäßen Bearbeiten der Bittiefe auf eInk-Geräten ist ebenfalls verfügbar und kann mit make fbdepth für E-Ink-Ziele erstellt werden.
Sein uninspirierter Name ist fbdepth und wird von KOReader auf Kobo und reMarkable verwendet, um eine vernünftige Rotation zu erzwingen und zu einer effizienteren Bittiefe zu wechseln. Es wurde auch auf dem Kindle getestet, wo sich die Rotationssteuerung zumindest ordnungsgemäß verhalten sollte. Beachten Sie, dass auf FW 5.x die Standard-GUI unter X läuft und X es nicht mag, wenn Sie die fb unter seinen Füßen wegdrehen ;).
Wenn Sie die kleinstmögliche Binärdatei wünschen, stellen Sie sicher, dass Sie sie allein aus einem makellosen Quellbaum erstellen.

Es gibt auch ein ziemlich dummes Beispiel, das die Dump/Restore-API zeigt, die über make dump erstellt werden kann.
Eine weitere dumme Demo, die auf dem PSX Doom-Feuereffekt basiert, wurde implementiert, um den EPDC auf eine einigermaßen interessante Weise einem Stresstest zu unterziehen.

Wenn Sie jemals neugierig auf den gesamten mxcfb alt_buffer Shindig waren, können Sie sich diesen PoC ansehen.

Wenn Sie sich mit Rotations- und Eingabe-Spielereien auf Kobo befassen, erstellt make devcap in gleicher Weise einen Tarball mit einigen Binärdateien und einem devcap_test.sh-Skript, das, wenn es auf dem Zielgerät ausgeführt wird, einiges davon kompiliert Info. Insbesondere wenn Sie jemals einen Fehler in fbdepth melden müssen, werde ich Sie wahrscheinlich bitten, diesen auszuführen und die Ergebnisse dem Problem beizufügen ;).

Und zum Thema Eingabe und Rotation auf Kobo: make ftrace wird ein einfaches Pointer-Trail-Dienstprogramm erstellen, das libevdev und einige unserer ausgefalleneren API-Aufrufe nutzt, um zu versuchen, die Eingabeübersetzungs-Spielereien auf Kobo zu verstehen.
Wenn Sie in Ihrem Code Berührungseingaben in irgendeiner Weise verarbeiten möchten, sollten Sie hier nachschauen ;).
Außerdem wird gezeigt, wie man effektiv mit der Stifteingabe und dem Zeichnen auf dem Elipsa umgeht.

Was make input_scan betrifft, so wird ein kleines CLI-Tool rund um die fbink_input_scan API erstellt, das dabei hilft, herauszufinden, welches Eingabegerät was tut (auch bekannt als „Wo ist dieser verdammte Touchscreen?“ ;)).

HINWEISE

Der Kindle-Support deckt die gesamte Kindle-Reihe ab, beginnend mit dem K2.

Die Kobo-Unterstützung deckt die gesamte Kobo-Reihe ab, beginnend mit dem Kobo Touch A/B/C (HINWEIS: Einige Funktionen sind auf Sunxi-SoCs nicht verfügbar, siehe API-Dokumente).

Die Unterstützung von BQ Cervantes wurde von @pazos (#17) beigesteuert und sollte die aktuelle Aufstellung abdecken.

Die reMarkable-Unterstützung wurde von @tcrs (#41) beigesteuert und unterstützt den rM2 in Kombination mit einer der verschiedenen rm2fb-Shim-Implementierungen.

Die PocketBook-Unterstützung wurde von @ezdiy (#47) getestet und sollte die gleichen Geräte wie KOReader unterstützen. Bedenken Sie, dass PocketBook eine ... komplizierte Plattform ist und dass ich selbst keinen Zugriff darauf habe. Das heißt, es gibt einige Macken:

• Wir verwenden InkView nicht zum Zeichnen, was unter anderem bedeutet, dass die Farbwiedergabe auf Farbgeräten nicht unterstützt wird und dass die Zuordnung des Wellenformmodus fraglich sein kann , insbesondere auf Geräten, die auf einem AW-SoC laufen (wir verwenden immer die mxcfb-Kernel-API). , und auf diesen Geräten ist es ein sehr, sehr, sehr eigenartiger Shim. Erwarten Sie seltsame und seltsame Fehler, insbesondere wenn Sie anfangen, mit Hardware-FB-Rotation zu spielen.
• Eine weitere Besonderheit, die besonders bei AW-Geräten auftritt, ist, dass die beiden fbinfo-Strukturen völlig gefälscht sind. FBInk bringt sie bei Init heuristisch in Form. Wenn Sie also Zugriff darauf benötigen, gehen Sie immer über fbink_get_fb_info , anstatt selbst auf die nativen ioctls zurückzugreifen.
• Apropos InkView: Standardmäßig wird es bei init geöffnet, um die Geräteidentifizierung zu erleichtern. Dies kann problematisch sein, da InkView über DT_NEEDED einen metrischen Crapton alter Bibliotheken abruft ... und einige davon beim Laden initialisiert, was ein perfektes Rezept für eine Katastrophe ist, wenn Sie selbst dieselben Bibliotheken verwenden, insbesondere wenn Sie Ich verwende verschiedene Versionen davon. Um dieses Durcheinander zu vermeiden, können Sie FBInk bitten, InkView niemals zu berühren, indem Sie die Variable FBINK_NO_INKVIEW in Ihrer Umgebung festlegen. Derzeit ist der einzige Nachteil die beeinträchtigte Geräteidentifizierung: insbesondere kein Gerätename und eine ungenaue DPI (wir verwenden standardmäßig 212, es sei denn, Sie legen eine Überschreibung über die Umgebungsvariable FBINK_FORCE_DPI fest)).
• Und was die Drehung angeht: Wenn das Gerät so aussieht , als ob seine ursprüngliche Ausrichtung im Querformat ist (was bei den meisten Geräten der Fall ist), erzwingt FBInk standardmäßig eine Softwarerotation, um Inhalte tatsächlich im Hochformat zu drucken (meistens). um die Interoperabilität mit KOReader zu unterstützen). Sie können dieses Verhalten deaktivieren, indem Sie die Variable FBINK_NO_SW_ROTA in Ihrer Umgebung festlegen. In diesem Fall zeichnen wir immer im nativen FB-Layout.

Verwandte Projekte

Wenn Sie, anstatt in den Framebuffer zu schreiben , einen PNG-Schnappschuss davon erstellen möchten (was nützlich sein kann), habe ich eine stark modifizierte Version von FBGrab, die die verschiedenen Macken von eInk-Framebuffern problemlos bewältigen sollte ;). Wenn Sie eigentlich keine PNG-Datei benötigen und nur mit In-Memory-FB-Dumps spielen möchten, schauen Sie sich die gesamten API-Aufrufe fbink_dump und fbink_restore an.

Einbände in anderen Sprachen

Damit alle Spaß haben, auch wenn du C nicht ausstehst!

Rost:

• fbink-sys von @Szybet (Nackte Bindungsbindungen)
• fbink-rs von @sublipri (Nur bindende Bindungen, einige sichere Wrapper, abhängig von Cross)

Go: go-fbink und sein Nachfolger go-fbink-v2 von @shermp

LuaJIT: lua-fbink von @NiLuJe

Python: py-fbink von @NiLuJe

Beachten Sie, dass diese alle an ein bestimmtes Tag (im Allgemeinen die neueste Version) gebunden sind, da die API auf dem Master möglicherweise nicht vollständig stabil ist. Sie sollten dieser Anforderung nachkommen, sonst bricht die Hölle los ;).
Im Allgemeinen versuche ich, Störungen auf ein Minimum zu beschränken oder, sofern dies nicht der Fall ist, die Upgrade-Pfade so einfach wie möglich zu gestalten, aber da haben Sie es schon: Die Unterstützung neuer Dinge bedeutet oft, dass bestehende Dinge etwas anders funktionieren müssen.

Ich versuche, API/ABI-Fehler in den Kommentaren jedes Tags detailliert darzustellen, aber eine gute Möglichkeit, dies zu veranschaulichen, besteht natürlich darin, den einzelnen öffentlichen Header zu unterscheiden (oder, für einen schnellen kontextlosen Überblick, die minimalen Header, die für FFI-Bindungen generiert werden) ;).