FBInk

FBInk

FrameBuffer eInker

Berlisensi di bawah GPLv3+. Bertempat di sini di GitHub.

Untuk apa?

Hal ini dimaksudkan untuk mengisi kekosongan yang dirasakan oleh pengembang dan pengotak-atik Kobo ketika mereka menyadari bahwa mereka tidak memiliki cara bawaan untuk mencetak sesuatu di layar perangkat!
Ini sangat kejam ketika berpindah ke Kobo, setelah terbiasa dengan eips yang ada di mana-mana di Kindle...

Singkatnya, ia mencetak pesan atau gambar di layar Anda, menangani pengerjaan tingkat rendah dengan antarmuka framebuffer Linux, dan i.MX EPDC (serta MTK di Kindle, dan sunxi di Kobo).
Ini telah diuji pada Kobo, Kindle, BQ Cervantes, reMarkable dan PocketBook, tetapi mem-portingnya ke Linux lain, perangkat i.MX eInk seharusnya menjadi hal yang sepele (bahkan dukungan Sipix pun tidak akan terlalu sulit). #64 membuktikan bahwa kami bahkan dapat mengubah API sunxi sesuai keinginan kami, jika Anda tidak terlalu peduli kehilangan kewarasan dalam prosesnya ;).

Secara default, rendering teks bergantung pada paket font bitmap sel tetap (lihat postingan ini untuk contoh kecil), namun berkat kontribusi @shermp (#20), Anda juga dapat mengandalkan rendering font TrueType/OpenType yang lengkap!

Dukungan gambar mencakup format paling umum (JPEG/PNG/TGA/BMP/GIF/PNM), serta piksel mentah dalam format piksel paling relevan (Gray8 & RGB32; keduanya +/- Alpha).

Ini juga berfungsi dengan baik pada semua jenis perangkat framebuffer Linux, dan mendukung berbagai kedalaman bit (4bpp, 8bpp, 16bpp, 24bpp & 32bpp), sehingga Anda dapat menggunakan ini untuk menggambar di fb EFI Anda, misalnya;) .

Bagaimana cara menginstal ini?

Untuk perangkat Kobo, ada rangkaian diskusi yang terbuka di sini di MobileRead, di mana Anda akan menemukan biner mandiri. Ini sengaja tidak memiliki petunjuk rinci, karena target audiensnya sebagian besar adalah pengembang dan pengotak-atik. Anggap ini sebagai tindakan pencegahan keamanan ;).

Ada juga thread saudara untuk perangkat Kindle di sini di mana, selain biner, Anda juga akan menemukan contoh orang yang melakukan hal-hal gila dengannya;).

Dalam praktiknya, sebagian besar pengguna Kindle & Kobo akan mendapatkannya secara gratis, karena sudah disertakan dengan sebagian besar paket saya.

Sebagai contoh penggunaan di alam liar, lihat KFMon, di mana saya menggunakannya untuk memberikan umpan balik visual, atau kobo-rclone, yang juga digunakan untuk screen scraping. Kami juga menggunakannya di KOReader, untuk membuat proses update OTA lebih ramah pengguna.
Pencarian cepat di GitHub untuk kode yang menyebutkan fbink juga akan memberikan hasil yang menarik, misalnya, shim yang menangani KERUSAKAN untuk X11, Qt5 QPA, atau InkVT, sebuah emulator terminal.
Lihat juga berbagai penjilidan dalam bahasa lain, yang sering kali menyertakan beberapa contoh.

Bagaimana saya bisa mengotak-atiknya?

Utilitas CLI tersedia, dibangun dengan API publik yang sama yang dapat digunakan melalui perpustakaan bersama atau statis untuk proyek C, atau melalui FFI dalam bahasa lain (hati-hati, ini dilisensikan di bawah GPLv3+, bukan LGPL). Untuk utilitas CLI, lihat dokumentasinya atau jalankan fbink --help untuk mengetahui detailnya. Untuk perpustakaan, lihat header publik. Jangan ragu untuk menghubungi saya jika ada yang tidak jelas!

CATATAN: Biasanya TIDAK ada upaya untuk menangani rotasi perangkat lunak, karena saat ini tampaknya hal tersebut merupakan hal yang benar untuk dilakukan dengan versi Kobo FW saat ini dan pada Kindle.
YMMV pada FW lama, atau jika ada sesuatu yang salah dengan rotasi fb, atau jika aplikasi Anda menerapkan rotasi dalam perangkat lunak (yaitu, area pandang yang diputar).
Terkait rotasi perangkat keras, ada beberapa pengecualian khusus yang dibuat untuk perangkat Kobo:

• Yang berjalan dalam mode 16bpp dan tampak dalam mode lanskap: karena tampaknya ini adalah kondisi aslinya, kami berupaya untuk mengimbanginya, karena kami dapat digunakan secara sah sebelum Nikel sendiri yang memperbaikinya.

• Pada perangkat dengan akselerometer, seperti Forma & Libra, di mana Nikel sendiri yang akan menangani perputaran perangkat keras.

Bagaimana tampilannya?

Beberapa contoh dasar rendering teks sel tetap...

Atau jika kita meletakkan gambar di sana...

Dan dengan semua fitur transparansi yang berfungsi, bahkan pada perangkat keras kuno :).

Berikut beberapa font lainnya, serta bilah kemajuan...

Dan saat menggunakan font TrueType yang mengkilap :).

Bagaimana cara membangunnya?

Kecuali Anda hanya mencoba mencobanya pada sistem Linux murni asli ( make linux ), Anda memerlukan kompiler silang yang menargetkan perangkat target Anda.
Makefile dirancang untuk secara otomatis mendeteksi pengaturan ToolChain kompilasi silang saya sendiri, yang jelas-jelas saya sarankan untuk digunakan daripada mengandalkan rantai alat kompilasi silang generik yang mungkin tidak secara tepat menargetkan duo kernel/libc yang tepat;).
Menggunakan frontend koxtoolchain seharusnya membuat pembuatan salah satu dari proses ini tidak terlalu merepotkan.

Jika Anda menggunakan rantai alat Anda sendiri, harap diperhatikan bahwa kami memerlukan dukungan C11 (GCC >= 4.9, Dentang >= 3.0).

Asalkan Anda tidak menggunakan kompiler lama, saya sangat merekomendasikan membangun ini dengan LTO diaktifkan!

Jika hal tersebut tidak terjadi, target default (yaitu, make ) akan menghasilkan build Kobo statis, sementara make kobo akan menghasilkan build bersama yang dilucuti, dan juga mengemas semuanya dengan cara Kobo. Paket yang ditemukan di thread Kobo dibuat dengan cara ini.

Ada beberapa target kenyamanan untuk tipe build biasa ( make static untuk build statis, make shared untuk build bersama, make strip untuk build statis yang dilucuti, make release untuk build bersama yang dilucuti, make debug untuk build debug), juga sebagai beberapa yang tidak biasa untuk kasus penggunaan yang sangat spesifik, biasanya terkait dengan pengikatan FFI ( make pic untuk build statis PIC, atau lewati STATIC_LIBM=1 untuk mencoba menautkan ke libm secara statis).

Pilihan platform target ditangani melalui variabel sederhana:

• Berikan KINDLE=1 untuk membuat build Kindle ( make kindle melakukan itu pada build statis yang dilucuti).
• Lewati KINDLE=1 LEGACY=1 untuk membuat build Kindle FW 2.x ( make legacy melakukan hal itu pada build statis yang dilucuti). Ini pada dasarnya hanya menonaktifkan CLOEXEC, yang mungkin tidak didukung pada FW 2.x.
• Lewati CERVANTES=1 untuk membuat build BQ/Cervantes ( make cervantes melakukan itu pada build statis yang dilucuti).
• Teruskan REMARKABLE=1 untuk membuat build reMarkable ( make remarkable melakukan hal itu pada build statis yang dilucuti).
• Berikan POCKETBOOK=1 untuk membuat build PocketBook ( make pocketbook melakukan itu pada build statis yang dilucuti).

Logika yang sama digunakan untuk memungkinkan sedikit penyesuaian:

• Lewati MINIMAL=1 untuk membuat build dengan fungsionalitas yang sangat terbatas (tanpa gambar primitif, tanpa rendering font sel tetap, tanpa rendering gambar, tanpa font tambahan, tanpa OpenType), yang menghasilkan aplikasi & pustaka yang jauh lebih kecil.
• Teruskan DEBUG=1 untuk membuat build Debug, dan teruskan DEBUG=1 DEBUGFLAGS=1 untuk membuat build Debug dengan CFLAGS debug yang diterapkan.

Anda juga dapat menambahkan fitur satu per satu ke build MINIMAL :

• Lewati DRAW=1 untuk menambahkan dukungan untuk menggambar primitif.
• Teruskan BITMAP=1 untuk menambahkan dukungan untuk rendering font sel tetap. (Menyiratkan DRAW )
• Teruskan FONTS=1 untuk menambahkan dukungan untuk font sel tetap tambahan yang dibundel. (Menyiratkan BITMAP )
• Lewati IMAGE=1 untuk menambahkan dukungan gambar. (Menyiratkan DRAW )
• Berikan OPENTYPE=1 untuk menambahkan dukungan rendering font OTF/TTF. (Menyiratkan DRAW )
• Lewati INPUT=1 untuk menambahkan dukungan untuk utilitas input.
• Lewati BUTTON_SCAN=1 untuk menambahkan dukungan untuk pemindaian tombol khusus Kobo. (Menyiratkan DRAW )

Jika Anda benar-benar membutuhkan cakupan Unicode yang ekstrem dalam jalur kode sel tetap, Anda juga dapat memilih untuk menyematkan GNU Unifont, dengan meneruskan UNIFONT=1 .
Berhati-hatilah karena ini akan menambah hampir 2MB ke ukuran biner, dan font tersebut sebenarnya terbagi menjadi dua (mesin terbang lebar ganda diselingi ke font tertentu), yang dapat mengurangi kegunaannya dalam praktik...
Untuk alasan yang jelas, ini tidak pernah diaktifkan secara default.
Kecuali Anda melakukan hal-hal yang sangat spesifik, biasanya Anda ingin setidaknya DRAW & BITMAP diaktifkan dalam build MINIMAL ...

Jangan lupa untuk menjalankan setidaknya make cleanlib ketika mengubah platform target atau tanda fitur, jika tidak, build perpustakaan terbaru yang cocok akan dipertahankan, karena akan memenuhi dependensi make;).

Sepanjang jalan, beberapa alat bantu mungkin muncul di folder utils . make utils akan melakukan build statis dari ini (yang merupakan cara yang disarankan untuk melakukannya, karena mereka secara kasar mendukung API internal FBInk). Saat ini, ini terdiri dari alat diagnostik mengenai perilaku rotasi, dan uji tekanan malapetaka yang disebutkan di bawah.
Sebagian besar hanya diuji pada Kobo, dan mungkin sebaiknya dibiarkan saja kecuali Anda tahu apa yang Anda lakukan ;).

Alat untuk memanipulasi kedalaman bit dengan benar pada perangkat eInk juga tersedia, dan dapat dibuat untuk target e-Ink dengan make fbdepth .
Namanya yang tidak menginspirasi adalah fbdepth , dan digunakan oleh KOReader di Kobo & reMarkable untuk menerapkan rotasi yang wajar dan beralih ke kedalaman bit yang lebih efisien. Ini juga telah diuji pada Kindle, di mana penanganan rotasi, setidaknya, harus berfungsi dengan baik. Perhatikan bahwa pada FW 5.x, GUI stok berjalan di bawah X, dan X tidak akan suka Anda memutar fb dari bawah kakinya;).
Jika Anda menginginkan biner sekecil mungkin, pastikan Anda membuatnya sendiri, dari pohon sumber asli.

Ada juga contoh yang cukup bodoh yang menampilkan API dump/restore yang dapat dibuat melalui make dump .
Demo bodoh lainnya berdasarkan efek api PSX Doom diterapkan, untuk menguji EPDC dengan cara yang agak menarik.

Jika Anda penasaran dengan keseluruhan mxcfb alt_buffer shindig, Anda dapat melihat PoC ini.

Dengan cara yang sama, jika Anda mencari rotasi & masukan yang rumit di Kobo, make devcap akan membuat tarball yang berisi beberapa biner dan skrip devcap_test.sh, yang, ketika dijalankan pada perangkat target, akan mengkompilasi cukup banyak info. Khususnya, jika Anda perlu melaporkan bug terhadap fbdepth , saya mungkin akan meminta Anda menjalankannya dan melampirkan hasilnya ke masalah tersebut ;).

Dan mengenai input & rotasi di Kobo, make ftrace akan membangun utilitas jejak penunjuk sederhana, yang memanfaatkan libevdev dan beberapa panggilan API kami yang lebih funkier untuk mencoba memahami kesalahan terjemahan input yang terjadi di Kobo.
Jika Anda ingin menangani input sentuh dengan cara apa pun dalam kode Anda, ini adalah tempat yang tepat untuk mencarinya ;).
Hal ini juga menunjukkan cara menangani input pena & menggambar secara efektif di Elipsa.

Sedangkan untuk make input_scan , ini akan membuat alat CLI kecil di sekitar API fbink_input_scan , yang membantu memahami perangkat input mana yang melakukan apa (alias, "di mana layar sentuh sialan itu?" ;)).

CATATAN

Dukungan Kindle mencakup seluruh jajaran Kindle, mulai dari K2.

Dukungan Kobo mencakup seluruh jajaran Kobo, mulai dari Kobo Touch A/B/C (CATATAN: beberapa fitur tidak tersedia di sunxi SoCs, cf, dokumen API).

Dukungan BQ Cervantes telah disumbangkan oleh @pazos (#17), dan harus menangani lineup saat ini.

dukungan reMarkable telah disumbangkan oleh @tcrs (#41), dan mendukung rM2 ketika dipasangkan dengan salah satu dari berbagai implementasi shim rm2fb.

Dukungan PocketBook telah diuji oleh @ezdiy (#47), dan seharusnya mendukung perangkat yang sama dengan KOReader. Ingatlah bahwa PocketBook adalah... platform yang rumit untuk ditangani, dan saya sendiri tidak memiliki akses ke sana. Artinya ada beberapa kebiasaan yang terlibat:

• Kami tidak menggunakan InkView untuk menggambar, yang berarti, di antara berbagai keanehan lainnya, rendering warna tidak didukung pada perangkat warna, dan pemetaan mode bentuk gelombang mungkin rapuh, terutama pada perangkat yang menjalankan SoC AW (kami selalu menggunakan API kernel mxcfb , dan pada perangkat tersebut, ini adalah shim yang sangat, sangat, sangat unik. Harapkan bug yang aneh dan aneh, terutama jika Anda mulai bermain dengan rotasi perangkat keras fb).
• Kekhasan lain yang lazim terjadi pada perangkat AW adalah kedua struct fbinfo sepenuhnya palsu. FBInk akan secara heuristik memotongnya menjadi bentuk di init, jadi jika Anda memerlukan akses ke sana, selalu gunakan fbink_get_fb_info daripada menggunakan sendiri ioctls asli.
• Berbicara tentang InkView, secara default, ini dibuka di init untuk membantu identifikasi perangkat. Ini bisa menjadi masalah, karena InkView menarik metrik perpustakaan lama melalui DT_NEEDED... dan menginisialisasi beberapa di antaranya saat dimuat, yang merupakan resep sempurna untuk bencana jika Anda sendiri menggunakan perpustakaan yang sama, terutama jika Anda 're menggunakan versi yang berbeda dari mereka. Untuk menghindari kekacauan ini, Anda dapat meminta FBInk untuk tidak pernah menyentuh InkView, dengan mengatur variabel FBINK_NO_INKVIEW di lingkungan Anda. Saat ini, satu-satunya kelemahan adalah identifikasi perangkat yang terganggu: khususnya, tidak ada nama perangkat, dan DPI yang tidak akurat (kami akan menggunakan default 212, kecuali Anda menyetel penggantian melalui env var FBINK_FORCE_DPI )).
• Dan mengenai subjek rotasi, secara default, jika perangkat tampak seperti orientasi aslinya adalah lanskap (yang terjadi pada sebagian besar jajaran), FBInk menerapkan rotasi perangkat lunak untuk benar-benar mencetak barang dalam Potret (kebanyakan untuk membantu interoperabilitas dengan KOReader). Anda dapat menonaktifkan perilaku ini dengan mengatur variabel FBINK_NO_SW_ROTA di lingkungan Anda, dalam hal ini kami akan selalu menggambar tata letak fb asli.

Proyek terkait

Jika, alih-alih menulis ke framebuffer, Anda ingin mengambil snapshot PNG-nya (yang mungkin berguna), saya memiliki versi FBGrab yang banyak dimodifikasi yang seharusnya menangani berbagai keunikan eInk framebuffers;). Jika Anda sebenarnya tidak membutuhkan file PNG dan hanya ingin bermain-main dengan fb dump dalam memori, lihat seluruh panggilan API fbink_dump & fbink_restore .

Binding dalam bahasa lain

Sehingga semua orang bisa bersenang-senang, meskipun Anda tidak tahan dengan C!

Karat:

• fbink-sys oleh @Szybet (Bindingan bare bindgen)
• fbink-rs oleh @sublipri (Bindingan bare bindgen, beberapa pembungkus yang aman, bergantung pada salib)

Go: go-fbink dan penerusnya go-fbink-v2 oleh @shermp

LuaJIT: lua-fbink oleh @NiLuJe

Python: py-fbink oleh @NiLuJe

Perhatikan bahwa karena API mungkin tidak sepenuhnya stabil pada master, semua ini terikat pada tag tertentu (umumnya, rilis terbaru). Anda harus menghormati persyaratan itu, atau kekacauan akan terjadi;).
Saya biasanya berusaha meminimalkan kerusakan, atau jika tidak, membuat jalur pemutakhiran semudah mungkin, namun, begitulah, mendukung hal-hal baru sering kali berarti hal-hal yang sudah ada harus bekerja sedikit berbeda.

Saya mencoba merinci kerusakan API/ABI di setiap komentar tag, tetapi cara yang baik untuk memvisualisasikannya tentu saja dengan membedakan satu header publik (atau, untuk ikhtisar cepat tanpa konteks, header minimal yang dihasilkan untuk pengikatan FFI);).