All Projects → NiLuJe → Fbink

NiLuJe / Fbink

Licence: gpl-3.0
FrameBuffer eInker, a small tool & library to print text & images to an eInk Linux framebuffer

Programming Languages

c
50402 projects - #5 most used programming language

Projects that are alternatives of or similar to Fbink

Kindlehelper
kindle助手,kindle最好的伙伴
Stars: ✭ 274 (+102.96%)
Mutual labels:  kindle
Readteractive
Tool for writing and generating interactive books.
Stars: ✭ 23 (-82.96%)
Mutual labels:  kindle
Linkindle
Générateur de graphiques de consommation d'électricité Linky pour affichage sur Kindle
Stars: ✭ 71 (-47.41%)
Mutual labels:  kindle
Kindlebookmaker
Kindle Book Maker with KindleGen, Make Book from RSS/single URL/directory and so on.
Stars: ✭ 364 (+169.63%)
Mutual labels:  kindle
Qs ledger
Quantified Self Personal Data Aggregator and Data Analysis
Stars: ✭ 559 (+314.07%)
Mutual labels:  kindle
Geektime dl
把极客时间装进 Kindle,内含快手内推等福利
Stars: ✭ 1,033 (+665.19%)
Mutual labels:  kindle
ComicBookMaker
Script to fetch webcomics and use them to create ebooks.
Stars: ✭ 27 (-80%)
Mutual labels:  kindle
The Economist Ebooks
经济学人(含音频)、纽约客、自然、新科学人、卫报、科学美国人、连线、大西洋月刊、新闻周刊、国家地理等英语杂志免费下载、订阅(kindle推送),支持epub、mobi、pdf格式, 每周更新. The Economist 、The New Yorker 、Nature、The Atlantic 、New Scientist、The Guardian、Scientific American、Wired、Newsweek magazines, free download and subscription for kindle, mobi、epub、pdf format.
Stars: ✭ 3,471 (+2471.11%)
Mutual labels:  kindle
Kindle Dash
Power efficient dashboard for Kindle 4 NT devices
Stars: ✭ 806 (+497.04%)
Mutual labels:  kindle
Kindle maker
a tool to make mobi-format file wich could be load into Kindle
Stars: ✭ 70 (-48.15%)
Mutual labels:  kindle
Epub Press Clients
📦 Clients for building books with EpubPress.
Stars: ✭ 370 (+174.07%)
Mutual labels:  kindle
Ansible For Devops
Ansible for DevOps examples.
Stars: ✭ 5,265 (+3800%)
Mutual labels:  kindle
Koreader
An ebook reader application supporting PDF, DjVu, EPUB, FB2 and many more formats, running on Cervantes, Kindle, Kobo, PocketBook and Android devices
Stars: ✭ 9,467 (+6912.59%)
Mutual labels:  kindle
Debiankindle
Scripts to install Debian on your Kindle
Stars: ✭ 313 (+131.85%)
Mutual labels:  kindle
Calibre
The official source code repository for the calibre ebook manager
Stars: ✭ 11,221 (+8211.85%)
Mutual labels:  kindle
Narou
Narou.rb - 小説家になろうのダウンローダ&縦書き整形&管理アプリ。Kindle(などの電子書籍端末)でなろうを読む場合に超便利です!
Stars: ✭ 256 (+89.63%)
Mutual labels:  kindle
Kindleclippings
Extract kindle highlights into organised text files
Stars: ✭ 24 (-82.22%)
Mutual labels:  kindle
Kmanga
KManga site
Stars: ✭ 134 (-0.74%)
Mutual labels:  kindle
Pwning Juice Shop
GitBook markdown content for the eBook "Pwning OWASP Juice Shop"
Stars: ✭ 110 (-18.52%)
Mutual labels:  kindle
Stories About Ming Dynasty
明朝那些事儿(全七卷)
Stars: ✭ 52 (-61.48%)
Mutual labels:  kindle

FBInk

License Total alerts Language grade: C/C++ Language grade: Python Codacy Badge Latest tag

FrameBuffer eInker

Licensed under the GPLv3+. Housed here on GitHub.

What's it for?

This is intended to fill the void felt by Kobo developers and tinkerers when they realize they do not have a builtin way to print stuff on the device's screen!
It's especially cruel when moving to a Kobo, after being used to the ubiquity of eips on Kindle...

In short, it prints messages or images on your screen, handling the low-level tinkering with both the Linux framebuffer interface, and the i.MX EPDC.
It's been tested on Kobo, Kindle, BQ Cervantes, reMarkable and PocketBook, but porting it to other Linux, i.MX eInk devices should be trivial (hell, even Sipix support shouldn't be too hard).

By default, text rendering relies on bundled fixed cell bitmap fonts (see this post for a small sampling), but thanks to @shermp's contributions (#20), you can also rely on full-fledged TrueType/OpenType font rendering!

Image support includes most common formats (JPEG/PNG/TGA/BMP/GIF/PNM), as well as raw packed pixels in the most relevant pixel formats (Gray8 & RGB32; both +/- Alpha).

It also happens to work perfectly fine on any kind of Linux framebuffer device, and supports a wide range of bitdepths (4bpp, 8bpp, 16bpp, 24bpp & 32bpp), so you could use this to draw on your EFI fb, for instance ;).

How do I install this?

For Kobo devices, there's a discussion thread open over here on MobileRead, where you'll happen to find standalone binaries. It's purposefully lacking in detailed instructions, because the target audience is mainly developers and tinkerers. Think of this as a safety precaution ;).

There's also a sister thread for Kindle devices over here where, besides binaries, you'll also find examples of people doing crazy things with it ;).

In practice, most Kindle & Kobo users will in fact get it for free, as it's bundled with most of my packages.

As an example of usage in the wild, see KFMon, where I'm using it to provide visual feedback, or kobo-rclone, where it's also used for screen scraping. We're also using it in KOReader, to make the OTA update process more user-friendly.
See also the various bindings in other languages, which often include a few examples.

How can I tinker with it?

A CLI utility is available, built around the same public API that can be used via a shared or static library for C projects, or via FFI in other languages (beware, though, it's licensed under the GPLv3+, not the LGPL).
The gist of the documentation is composed of the various comments in the public header, detailing how the API can be used, and what for. Don't hesitate to contact me if things appear unclear!
You can also launch the fbink CLI tool itself with no argument for a quick manual & rundown of its capabilities.

NOTE: It generally makes NO attempt at handling software rotation, because that currently appears to be the right thing to do with both current Kobo FW versions and on Kindle.
YMMV on older FW, or if something else is fudging with fb rotation, or if your application is implementing rotation in software (i.e., a rotated viewport).
As far as hardware rotation is concerned, there are a few specific exceptions made for Kobo devices:

  • Those running in 16bpp mode and appearing to be in landscape mode: since that seems to be their native state, we attempt to compensate for this, as we can legitimately be used before Nickel itself corrects this.

  • On devices with an accelerometer, like the Forma & Libra, where Nickel itself will handle the hardware rotation.

How does it look?

A few basic examples of the fixed cell text rendering...

FBInk on a Kobo H2O

Or if we drop an image in there...

FBInk 1.2.0 on a Kobo H2O

And with all the bells and whistles of working transparency, even on ancient hardware :).

FBInk 1.2.5 on a Kindle 3

Here's a few other fonts, as well as a progress bar...

FBInk 1.6.2 on a Kobo H2O

And when using shiny TrueType fonts :).

FBInk 1.8.0 on a Kobo H2O

How do I build it?

Unless you're just trying to take it for a spin on a native pure Linux system (make linux), you'll need a cross-compiler targeting your, well, target device.
The Makefile is tailored to automatically detect my own cross-compilation ToolChain setups, which I evidently heartily recommend using instead of relying on generic cross-compilation toolchains which may not exactly target the right kernel/libc duo ;).
Using the koxtoolchain frontend should make building one of these a fairly painless process.

In case you're using your own toolchain, please note that we require C11 support (GCC >= 4.9, Clang >= 3.0).

Provided you're not using an older compiler, I highly recommend building this with LTO enabled!

With that out of the way, the default target (i.e., make) will yield a static Kobo build, while make kobo will yield a stripped shared build, and additionally package everything the Kobo way. The package found in the Kobo thread is built this way.

There's a few convenience targets for usual build types (make static for a static build, make shared for a shared build, make strip for a stripped static build, make release for a stripped shared build, make debug for a debug build), as well as a few unusual ones for very specific use cases, usually related to FFI bindings (make pic for a PIC static build, or passing STATIC_LIBM=1 to make to attempt to link against libm statically).

The choice of target platform is handled via a simple variable:

  • Pass KINDLE=1 to make for a Kindle build (make kindle does that on a stripped static build).
  • Pass KINDLE=1 LEGACY=1 to make for a FW 2.x Kindle build (make legacy does that on a stripped static build). This basically just disables CLOEXEC, which might not be supported on FW 2.x.
  • Pass CERVANTES=1 to make for a BQ/Cervantes build (make cervantes does that on a stripped static build).
  • Pass REMARKABLE=1 to make for a reMarkable build (make remarkable does that on a stripped static build).
  • Pass POCKETBOOK=1 to make for a PocketBook build (make pocketbook does that on a stripped static build).

The same logic is used to allow for a bit of tailoring:

  • Pass MINIMAL=1 to make for a build with limited functionality (only fixed cell font rendering, no image rendering, no extra fonts, no OpenType), which yields a much smaller application & library.
  • Pass DEBUG=1 to make for a Debug build, and pass DEBUG=1 DEBUGFLAGS=1 to make for a Debug build with enforced debug CFLAGS.

You can also append features one by one to a MINIMAL build:

  • Pass FONTS=1 to add support for the extra bundled fixed-cell fonts.
  • Pass IMAGE=1 to add image support.
  • Pass OPENTYPE=1 to add OTF/TTF font rendering support.
  • Pass BUTTON_SCAN=1 to add support for the Kobo-specific button scan stuff.

If you really need extreme Unicode coverage in the fixed-cell codepath, you can also choose to embed GNU Unifont, by passing UNIFONT=1.
Be warned that this'll add almost 2MB to the binary size, and that the font is actually split in two (double-wide glyphs are punted off to a specific font), which may dampen its usefulness in practice...
For obvious reasons, this is never enabled by default.

Along the way, a few auxiliary tools may crop up in the utils folder. make utils will do a static build of these (which is the recommended way to do it, as they rather crudely piggyback on FBInk's internal API). Currently, these consist of a diagnostic tool regarding rotation behavior, and a tool to properly manipulate the bitdepth on eInk devices.
Most of these have only been tested on Kobo, and should probably be left alone unless you know what you're doing ;).
The main exception would be (fbdepth), which is used by KOReader on Kobo & reMarkable to enforce a sane rotation and switch to a more efficient bitdepth. It has also been tested on Kindle, where rotation handling, at the very least, should be behaving properly. Do note that on FW 5.x, the stock GUI runs under X, and X will not like you rotating the fb from under its feet ;).

There's also a fairly stupid example showcasing the dump/restore API that can be built via make dump.
Another stupid demo based on the PSX Doom fire effect was implemented, to stress-test the EPDC in a mildly interesting manner.

If you ever were curious about the whole mxcfb alt_buffer shindig, you can take a look at this PoC.

In the same vein, if you're looking into rotation & input shenanigans on Kobo, make devcap will build a tarball containing a few binaries and a devcap_test.sh script, that, when run on the target device, will compile quite a bit of info. In particular, if you ever need to report a bug against fbdepth, I'll probably ask you to run that and attach the results to the issue ;).

NOTES

Kindle support covers the full Kindle lineup, starting from the K2.

Kobo support covers the full Kobo lineup, starting from the Kobo Touch A/B/C.

BQ Cervantes support has been contributed by @pazos (#17), and should handle the current lineup.

reMarkable support has been contributed by @tcrs (#41).

PocketBook support was tested by @ezdiy (#47), and should support the same set of devices as KOReader.

If, instead of writing to the framebuffer, you want to grab a PNG snapshot of it (which can come in handy), I have a heavily modified version of FBGrab that should sanely deal with the various quirks of eInk framebuffers ;).

Bindings in other languages

So that everyone gets to have fun, even if you can't stand C!

Go: go-fbink and its successor go-fbink-v2 by @shermp

LuaJIT: lua-fbink by @NiLuJe

Python: py-fbink by @NiLuJe

Note that as the API may not be entirely stable on master, these are all tethered to a specific tag (generally, the latest release). You should honor that requirement, or all hell will break loose ;).
I generally attempt to keep breakages to a minimum, or barring that, make the upgrade paths as painless as possible, but, there you have it, supporting new stuff often means existing stuff has to work slightly differently.

I try to detail API/ABI breakages in each tag's comments, but a good way to visualize that is of course to diff the single public header (or, for a quick contextless overview, the minimal headers generated for FFI bindings) ;).

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].