FB墨水

FB墨水

幀緩衝電子墨水

依據 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；均為 +/- Alpha）。

它也恰好可以在任何類型的 Linux 幀緩衝設備上完美工作，並且支援各種位元深度（4bpp、8bpp、16bpp、24bpp 和 32bpp），因此您可以使用它在您的 EFI fb 上繪圖，例如；） 。

我該如何安裝這個？

對於 Kobo 設備，MobileRead 上有一個討論線程，您可以在其中找到獨立的二進位。它故意缺乏詳細的說明，因為目標受眾主要是開發人員和修補匠。將此視為安全預防措施；）。

這裡還有一個針對 Kindle 設備的姐妹線程，除了二進位檔案之外，您還可以找到人們用它做瘋狂事情的範例;)。

實際上，大多數 Kindle 和 Kobo 用戶實際上都會免費獲得它，因為它與我的大多數軟體包捆綁在一起。

作為實際使用的範例，請參閱 KFMon（我使用它來提供視覺回饋）或 kobo-rclone（它也用於螢幕抓取）。我們也在 KOReader 中使用它，以使 OTA 更新過程更加用戶友好。
在 GitHub 上快速搜尋提到 fbink 的程式碼也應該會產生有趣的結果，例如 X11 的 DAMAGE 處理墊片、Qt5 QPA 或 InkVT、終端模擬器。
另請參閱其他語言中的各種綁定，其中通常包含一些範例。

我該如何修改它？

CLI 實用程式可用，圍繞著相同的公共 API 構建，可透過 C 專案的共享或靜態庫使用，或透過其他語言的 FFI 使用（但要注意，它是根據 GPLv3+ 而不是 LGPL 授權的）。對於 CLI 實用程序，請參閱其文件或運行fbink --help以了解詳細資訊。對於庫，請參閱公共標頭。如果事情不清楚，請隨時與我聯繫！

注意：它通常不會嘗試處理軟體輪換，因為目前看來，對於當前的 Kobo FW 版本和 Kindle 來說，這似乎都是正確的做法。
YMMV 在較舊的韌體上，或者如果其他東西與 fb 旋轉有關，或者您的應用程式正在軟體中實現旋轉（即旋轉視口）。
就硬體輪換而言，Kobo 設備有一些特定的例外：

• 那些在 16bpp 模式下運行且看起來處於橫向模式的：因為這似乎是它們的本機狀態，我們嘗試對此進行補償，因為我們可以在 Nickel 本身糾正此問題之前合法使用。

• 在具有加速計的裝置上，例如 Forma 和 Libra，Nickel 本身將處理硬體旋轉。

看起來怎麼樣？

固定單元格文字渲染的一些基本範例...

或者如果我們把圖像放在那裡......

並具有工作透明度的所有花哨功能，即使在古老的硬體上:)。

這是一些其他字體，以及進度條...

使用閃亮的 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 ，或傳遞STATIC_LIBM=1以嘗試靜態連結 libm）。

目標平台的選擇是透過一個簡單的變數來處理的：

• 傳遞KINDLE=1以進行 Kindle 建置（ make kindle在剝離的靜態建置上執行此操作）。
• 傳遞KINDLE=1 LEGACY=1來建構 FW 2.x Kindle（ make legacy在剝離的靜態建置上執行此操作）。這基本上只是禁用 CLOEXEC，FW 2.x 可能不支援 CLOEXEC。
• 傳遞CERVANTES=1以進行 BQ/Cervantes 建置（ make cervantes在剝離的靜態建置上執行此操作）。
• 傳遞REMARKABLE=1來進行 reMarkable 建置（在剝離的靜態建置上make remarkable ）。
• 傳遞POCKETBOOK=1以進行 PocketBook 建置（ make pocketbook在剝離的靜態建置上執行此操作）。

使用相同的邏輯可以進行一些自訂：

• 透過MINIMAL=1來建立功能非常有限的建置（無繪圖基元、無固定單元字體渲染、無影像渲染、無額外字體、無 OpenType），這會產生較小的應用程式和函式庫。
• 傳遞DEBUG=1以進行調試構建，並傳遞DEBUG=1 DEBUGFLAGS=1以使用強制調試 CFLAGS 進行調試構建。

您也可以將功能一一附加到MINIMAL建置中：

• 傳遞DRAW=1以新增對繪圖基元的支援。
• 傳遞BITMAP=1以新增對固定單元字體渲染的支援。 （表示DRAW ）
• 傳遞FONTS=1以新增對額外捆綁的固定單元字體的支援。 （表示BITMAP ）
• 傳遞IMAGE=1以新增圖像支援。 （表示DRAW ）
• 透過OPENTYPE=1添加 OTF/TTF 字體渲染支援。 （表示DRAW ）
• 傳遞INPUT=1以新增對輸入實用程式的支援。
• 透過BUTTON_SCAN=1新增對 Kobo 特定按鈕掃描內容的支援。 （表示DRAW ）

如果您確實需要在固定單元程式碼路徑中實現極端的Unicode 覆蓋，您也可以選擇透過傳遞UNIFONT=1來嵌入 GNU Unifont。
請注意，這將增加近 2MB 的二進位大小，並且字體實際上被分成兩部分（雙寬字形被轉為特定字體），這可能會削弱它在實踐中的實用性...
由於顯而易見的原因，預設情況下永遠不會啟用此功能。
除非您正在做非常具體的事情，否則您通常希望至少在MINIMAL構建中啟用DRAW和BITMAP ...

在更改目標平台或功能標誌時，不要忘記至少運行make cleanlib ，否則將保留最新的匹配庫構建，因為它將填充 make 依賴項;)。

在此過程中， utils資料夾中可能會出現一些輔助工具。 make utils將對這些進行靜態建置（這是建議的方法，因為它們相當粗暴地依賴 FBInk 的內部API）。目前，這些包括有關輪換行為的診斷工具和下面提到的厄運壓力測試。
其中大部分僅在 Kobo 上進行過測試，除非您知道自己在做什麼，否則應該不要管它；）。

還可以使用正確操作電子墨水設備上的位元深度的工具，並且可以使用make fbdepth為電子墨水目標構建。
它的名字很平淡，叫做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 系列，從 Kobo Touch A/B/C 開始（注意：某些功能在 sunxi SoC 上不可用，請參閱 API 文件）。

BQ Cervantes 支援由 @pazos (#17) 提供，並且應該能夠處理目前的陣容。

reMarkable 支援由 @tcrs (#41) 貢獻，並且在與各種 rm2fb shim 實作之一配對時支援 rM2。

PocketBook 支援由 @ezdiy (#47) 測試，並且應該支援與 KOReader 相同的裝置集。請記住，PocketBook 是一個...處理起來很複雜的平台，而且我自己無法存取它。這意味著涉及很多怪癖：

• 我們不使用 InkView 進行繪圖，這意味著，除了其他各種怪癖之外，彩色設備不支援顏色渲染，而且波形模式映射可能不穩定，尤其是在AW SoC 上運行的設備上（我們始終使用mxcfb 內核API） ，並且在這些設備上，這是一個非常、非常、非常古怪的墊片，預計會出現奇怪的錯誤，尤其是當您開始使用硬體 fb 旋轉時。
• AW 設備上特別普遍的另一個怪癖是兩個 fbinfo 結構完全是偽造的。 FBInk 會在 init 時試探性地將它們打亂，因此如果您碰巧需要訪問它們，請始終通過fbink_get_fb_info而不是自己求助於本機 ioctl。
• 說到 InkView，預設情況下，它會在 init 上開啟以幫助裝置識別。這可能會出現問題，因為 InkView 通過 DT_NEEDED 提取舊庫的度量 crapton...並在加載時初始化其中一些庫，如果您碰巧自己使用這些相同的庫，這將是一個完美的災難配方，特別是如果您正在使用它們的不同版本。為了避免這種混亂，您可以透過在環境中設定FBINK_NO_INKVIEW變數來要求 FBInk永遠不要觸摸 InkView。目前，唯一的缺點是設備識別受損：具體來說，沒有設備名稱，且 DPI 不準確（我們預設為 212，除非您透過FBINK_FORCE_DPI環境變數設定覆蓋）。
• 關於旋轉主題，預設情況下，如果裝置看起來其原始方向是橫向方向（這在大多數產品系列中都是如此），FBInk 會強制執行軟體旋轉，以便實際以縱向方式列印內容（大多數情況下）以幫助與 KOReader 的互通性）。您可以透過在環境中設定FBINK_NO_SW_ROTA變數來停用此行為，在這種情況下，我們將始終在本機 fb 版面配置中進行繪製。

相關項目

如果您不想寫入幀緩衝區，而是想獲取它的PNG 快照（這會派上用場），我有一個經過大量修改的FBGrab 版本，它應該能夠合理地處理電子墨水幀緩衝區的各種怪癖; )。如果您實際上不需要 PNG 檔案而只想使用記憶體中的 fb 轉儲，請查看整個fbink_dump和fbink_restore API 呼叫。

其他語言的綁定

這樣每個人都能玩得開心，即使你無法忍受 C！

鏽：

• fbink-sys by @Szybet（裸bindgen綁定）
• fbink-rs by @sublipri （裸綁定產生綁定，一些安全包裝器，依賴交叉）

Go：go-fbink 及其後繼者 go-fbink-v2，作者：@shermp

LuaJIT：lua-fbink 作者：@NiLuJe

Python：py-fbink 作者：@NiLuJe

請注意，由於 API 在 master 上可能不完全穩定，因此這些 API 都會綁定到特定標籤（通常是最新版本）。你應該遵守這個要求，否則一切都會崩潰;)。
我通常會嘗試將損壞保持在最低限度，或者除非出現這種情況，否則，請使升級路徑盡可能輕鬆，但是，你已經知道了，支持新東西通常意味著現有東西的工作方式必須略有不同。

我嘗試在每個標籤的註釋中詳細說明API/ABI 損壞，但可視化的一個好方法當然是區分單個公共標頭（或者，為了快速無上下文概述，為FFI 綁定生成的最小標頭）；） 。