FBインク
v1.25.0: SoC Puppet
FrameBuffer eInker
GPLv3+ に基づいてライセンスされています。ここ GitHub に保管されています。
これは、デバイスの画面上に何かを印刷する組み込みの方法がないことに気づいた Kobo の開発者や改造者が感じる空白を埋めることを目的としています。
Kindle でのeipsの普及に慣れた後に kobo に移行するときは特に残酷です...
つまり、Linux フレームバッファ インターフェイスと i.MX EPDC (Kindle の MTK や Kobo の sunxi も同様) の両方を使った低レベルの操作を処理しながら、メッセージや画像を画面に表示します。
Kobo、Kindle、BQ Cervantes、reMarkable、PocketBook でテストされていますが、他の Linux、i.MX eInk デバイスへの移植は簡単なはずです (Sipix のサポートでさえ、それほど難しくないはずです)。 #64 は、途中で正気を失うことをあまり気にしなければ、Sunxi API を自分の意志に合わせて曲げることもできることを証明しました ;)。
デフォルトでは、テキスト レンダリングはバンドルされた固定セル ビットマップ フォントに依存します (小規模なサンプルについてはこの投稿を参照してください) が、@shermp の貢献 (#20) のおかげで、本格的な TrueType/OpenType フォント レンダリングに依存することもできます。
画像サポートには、最も一般的な形式 (JPEG/PNG/TGA/BMP/GIF/PNM) に加え、最も関連性の高いピクセル形式 (Gray8 および RGB32、両方 +/- アルファ) の生のパックされたピクセルが含まれます。
また、あらゆる種類の Linux フレームバッファ デバイスでも完全に問題なく動作し、幅広いビット深度 (4bpp、8bpp、16bpp、24bpp & 32bpp) をサポートしているため、これを使用して、たとえば EFI FB に描画することもできます ;) 。
Kobo デバイスについては、MobileRead でディスカッション スレッドが開かれており、そこでスタンドアロン バイナリを見つけることができます。対象読者は主に開発者や改造者であるため、詳細な手順は意図的に省略されています。これは安全上の予防策として考えてください ;)。
ここには Kindle デバイス用の姉妹スレッドもあり、バイナリのほかに、それを使っておかしなことをしている人々の例も見つかります ;)。
実際、ほとんどの Kindle と kobo ユーザーは、ほとんどのパッケージにバンドルされているため、実際には無料で入手できます。
実際の使用例として、視覚的なフィードバックを提供するために使用している KFMon 、または画面スクレイピングにも使用されている kobo-rclone を参照してください。 OTA アップデート プロセスをより使いやすくするために、KOReader でもこれを使用しています。
fbink に言及しているコードを GitHub で簡単に検索すると、X11 用の DAMAGE 処理シム、Qt5 QPA または InkVT、ターミナル エミュレータなど、興味深い結果が得られるはずです。
他の言語のさまざまなバインディングも参照してください。多くの場合、いくつかの例が含まれています。
CLI ユーティリティは利用可能で、同じパブリック API を中心に構築されており、C プロジェクトの共有ライブラリまたは静的ライブラリを介して、または他の言語の FFI を介して使用できます (ただし、LGPL ではなく GPLv3+ に基づいてライセンスされていることに注意してください)。 CLI ユーティリティの詳細については、ドキュメントを参照するか、 fbink --helpを実行してください。ライブラリについては、パブリックヘッダーを参照してください。ご不明な点がございましたら、お気軽にご連絡ください。
注: 通常、ソフトウェアのローテーションを処理する試みはありません。これは、現在の Kobo FW バージョンと Kindle の両方で、ソフトウェアのローテーションを行うことが現在正しいと思われるためです。
古い FW 上の YMMV、または何か他のものが FB 回転でごまかしている場合、またはアプリケーションがソフトウェアで回転を実装している場合 (つまり、回転されたビューポート)。
ハードウェアのローテーションに関する限り、Kobo デバイスにはいくつかの特定の例外があります。
16bpp モードで実行されており、ランドスケープ モードであるように見えるもの: これがネイティブ状態であると思われるため、Nickel 自体がこれを修正する前に合法的に使用できるように、これを補おうとします。
Forma や Libra などの加速度センサーを備えたデバイスでは、ニッケル自体がハードウェアの回転を処理します。
固定セルのテキストレンダリングの基本的な例をいくつか...
あるいは、そこに画像をドロップすると...
そして、古いハードウェアであっても、透明性を保つためのあらゆる付加機能が備わっています:)。
ここには他のいくつかのフォントと進行状況バーがあります...
そして、光沢のある TrueType フォントを使用する場合:)。
ネイティブの純粋な Linux システム ( make linux ) で試してみようとしているだけでない限り、ターゲット デバイスを対象としたクロスコンパイラーが必要になります。
Makefile は、私自身のクロスコンパイル ツールチェーン設定を自動的に検出するように調整されており、適切なカーネル/libc デュオを正確にターゲットにしていない可能性がある汎用クロスコンパイル ツールチェーンに依存する代わりに、これを使用することを心からお勧めします ;)。
koxtoolchain フロントエンドを使用すると、これらのいずれかを構築するプロセスがかなり楽になります。
独自のツールチェーンを使用している場合は、C11 サポート (GCC >= 4.9、Clang >= 3.0) が必要であることに注意してください。
古いコンパイラを使用していない限り、LTO を有効にしてこれをビルドすることを強くお勧めします。
さて、デフォルトのターゲット (つまり、 make ) は静的な Kobo ビルドを生成しますが、 make koboストリップされた共有ビルドを生成し、さらに Kobo の方法ですべてをパッケージ化します。 Kobo スレッドで見つかったパッケージはこの方法で構築されています。
通常のビルド タイプには便利なターゲットがいくつかあります (静的ビルドの場合はmake static 、共有ビルドの場合はmake shared 、ストリップされた静的ビルドの場合はmake strip 、ストリップされた共有ビルドの場合はmake release 、デバッグ ビルドの場合はmake debug ) も同様です。非常に特殊なユースケース向けのいくつかの珍しいものとして、通常は FFI バインディングに関連しています (PIC 静的ビルドの場合はmake picか、静的に libm に対してリンクを試みるためにSTATIC_LIBM=1渡すなど)。
ターゲット プラットフォームの選択は、単純な変数を介して処理されます。
KINDLE=1を渡します ( make kindleストリップされた静的ビルドでこれを実行します)。KINDLE=1 LEGACY=1を渡して FW 2.x Kindle ビルドを作成します ( make legacyストリップされた静的ビルドでこれを実行します)。これは基本的に CLOEXEC を無効にするだけですが、FW 2.x ではサポートされていない可能性があります。CERVANTES=1渡して BQ/Cervantes ビルドを作成します ( make cervantesストリップされた静的ビルドでこれを行います)。REMARKABLE=1を渡して、reMarkable ビルドを作成します ( make remarkable )。POCKETBOOK=1を渡します ( make pocketbookストリップされた静的ビルドでこれを実行します)。同じロジックを使用して、少しの調整を可能にします。
MINIMAL=1を渡すと、機能が非常に制限されたビルド (描画プリミティブなし、固定セル フォント レンダリングなし、イメージ レンダリングなし、追加フォントなし、OpenType なし) が作成され、アプリケーションとライブラリが大幅に小さくなります。DEBUG=1を渡し、デバッグ CFLAGS を強制したデバッグ ビルドを作成するにはDEBUG=1 DEBUGFLAGS=1渡します。 MINIMALビルドに機能を 1 つずつ追加することもできます。
DRAW=1を渡すと、描画プリミティブのサポートが追加されます。BITMAP=1を渡すと、固定セル フォント レンダリングのサポートが追加されます。 ( DRAW暗黙的に示します)FONTS=1を渡します。 ( BITMAP暗黙的に示します)IMAGE=1を渡します。 ( DRAW暗黙的に示します)OPENTYPE=1を渡します。 ( DRAW暗黙的に示します)INPUT=1を渡すと、入力ユーティリティのサポートが追加されます。BUTTON_SCAN=1を渡して、Kobo 固有のボタン スキャン機能のサポートを追加します。 ( DRAW暗黙的に示します)固定セルのコードパスで Unicode を最大限にカバーする必要がある場合は、 UNIFONT=1を渡して GNU Unifont を埋め込むことも選択できます。
これにより、バイナリ サイズが 2MB 近く増加することと、フォントが実際には 2 つに分割される (倍幅のグリフは特定のフォントにパントオフされる) ため、実際の有用性が損なわれる可能性があることに注意してください...
明らかな理由により、これがデフォルトで有効になることはありません。
よほど特殊なことをしている場合を除いて、 MINIMALビルドでは少なくともDRAWとBITMAP有効にする必要があります...
ターゲット プラットフォームや機能フラグを変更する場合は、少なくともmake cleanlibを実行することを忘れないでください。そうしないと、make の依存関係が満たされるため、一致する最新のライブラリ ビルドが保持されます ;)。
その過程で、いくつかの補助ツールがutilsフォルダーに現れる場合があります。 make utilsこれらの静的ビルドを実行します (FBInk の内部API にかなり大雑把に便乗しているため、これをお勧めします)。現在、これらは回転動作に関する診断ツールと、後述するドゥーム ストレス テストで構成されています。
これらのほとんどは kobo でのみテストされており、何をしているのか分からない限り、おそらく放っておくべきです ;)。
eInk デバイスのビット深度を適切に操作するツールも利用可能で、 make fbdepthを使用して e-Ink ターゲット用に構築できます。
その平凡な名前はfbdepthで、正常な回転を強制し、より効率的なビット深度に切り替えるために、Kobo & reMarkable の KOReader によって使用されます。 Kindle でもテストされており、少なくとも回転処理は適切に動作するはずです。 FW 5.x では、ストック GUI は X で実行され、X は足元から FB を回転させることを好まないことに注意してください ;)。
可能な限り最小のバイナリが必要な場合は、必ず元のソース ツリーから単独でビルドしてください。
make dumpで構築できるダンプ/復元 API を紹介するかなり愚かな例もあります。
PSX Doom の火災エフェクトに基づいた別の愚かなデモが実装され、やや興味深い方法で EPDC のストレス テストが行われました。
mxcfb alt_buffer shindig 全体に興味がある場合は、この PoC を参照してください。
同様に、Kobo での回転と入力の悪ふざけを調べている場合、 make devcapいくつかのバイナリと devcap_test.sh スクリプトを含む tarball を構築します。ターゲット デバイス上で実行すると、かなりの量のコンパイルが行われます。情報。特に、 fbdepthに対するバグを報告する必要がある場合は、おそらくそれを実行して結果を問題に添付するようお願いするでしょう ;)。
そして、Kobo での入力と回転に関して言えば、 make ftraceシンプルなポインター トレイル ユーティリティを構築します。これは、libevdev といくつかのファンキーな API 呼び出しを利用して、Kobo で起こっている入力変換の悪ふざけを理解しようとします。
コード内で何らかの方法でタッチ入力を処理する予定がある場合は、ここを参照すると良いでしょう ;)。
また、Elipsa でのペン入力と描画を効果的に処理する方法も示します。
make input_scanに関しては、 fbink_input_scan API を中心に小さな CLI ツールを構築します。これは、どの入力デバイスが何を行うかを理解するのに役立ちます (別名、「あのタッチスクリーンはどこにあるの?」 ;))。
Kindle のサポートは、K2 から始まる Kindle の全ラインナップをカバーします。
kobo のサポートは、kobo Touch A/B/C から始まる kobo の全ラインナップをカバーしています (注: 一部の機能は sunxi SoC では利用できません、API ドキュメントを参照)。
BQ Cervantes のサポートは @pazos (#17) によって提供されており、現在のラインナップを処理する必要があります。
reMarkable のサポートは @tcrs (#41) によって提供されており、さまざまな rm2fb シム実装の 1 つと組み合わせた場合に rM2 をサポートします。
PocketBook のサポートは @ezdiy (#47) によってテストされており、KOReader と同じデバイスのセットをサポートするはずです。 PocketBook は扱いが複雑なプラットフォームであり、私自身はそれにアクセスできないことに留意してください。つまり、かなりの数の奇妙な点が含まれています。
fbink_get_fb_infoを使用してください。FBINK_NO_INKVIEW変数を設定することにより、FBInk が InkView に触れないようにすることができます。現時点での唯一の欠点は、デバイスの識別が損なわれることです。具体的には、デバイス名がないことと、DPI が不正確です ( FBINK_FORCE_DPI環境変数でオーバーライドを設定しない限り、デフォルトは 212 になります)。FBINK_NO_SW_ROTA変数を設定することでこの動作を無効にできます。その場合、常にネイティブ FB レイアウトで描画されます。 フレームバッファに書き込む代わりに、フレームバッファの PNG スナップショットを取得したい場合 (これは便利です)、eInk フレームバッファのさまざまな癖に適切に対処できる大幅に変更されたバージョンの FBGrab を用意しています ;)。実際には PNG ファイルが必要なく、メモリ内の FB ダンプを操作したいだけの場合は、 fbink_dumpおよびfbink_restore API 呼び出し全体を調べてください。
Cが苦手でもみんなで楽しめるように！
さび：
Go: go-fbink とその後継 go-fbink-v2 by @shermp
LuaJIT: lua-fbink by @NiLuJe
Python: py-fbink by @NiLuJe
API はマスター上で完全に安定していない可能性があるため、これらはすべて特定のタグ (通常は最新リリース) に関連付けられていることに注意してください。その要件を尊重する必要があります。そうしないと、すべての地獄が解き放たれます ;)。
私は通常、破損を最小限に抑えるか、それを除けばアップグレード パスをできるだけ簡単に行うように努めますが、ご存知のとおり、新しいものをサポートするということは、既存のものがわずかに異なる動作をしなければならないことを意味することがよくあります。
各タグのコメントで API/ABI の破損を詳しく説明しようとしていますが、それを視覚化する良い方法は、もちろん、単一のパブリック ヘッダー (または、コンテキストのない概要を簡単に説明するために、FFI バインディング用に生成された最小限のヘッダー) の差分を確認することです ;)。
