NiLuJe / FBInk

FrameBuffer eInker, a small tool & library to print text & images to an eInk Linux framebuffer

Home Page:https://www.mobileread.com/forums/showthread.php?t=299110

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How to use as library?

cyclops1982 opened this issue · comments

commented

Hi,

I've got a kindle basic 2 from 2014.
I would like to use lvgl to build a UI on the kindle, sort of like this: https://github.com/embeddedt/lv_port_kobo

Now, i'm wondering how i can use FBInk as a library. Are there any docs that explain this?

commented

LVGL doesn't appear to support grayscale only displays, and I don't recall how sanely old Kindles like that handle RGB565 (as that's probably the highest you can go, I'm not sure the actual framebuffer is large enough for RGB32).

Barring these low-level concerns, you should basically be able to simply send an fbink_refresh call in the flush callback and call it a day?

(I'd probably start from the current fbdev driver instead of that kobo one, though?)

commented

I might give this a try myself on Kobo this WE, FWIW ;o).

commented

Small other random comments:

  • The depth issue can be dealt with via fbink_set_fb_info on (lvgl) init. Re: my Kindle concerns above, you can double-check that first via the fbdepth & fbink CLI tools.
  • Depending on how LVGL does stuff when drawing, you should be able to forgo its shadow buffer approach and just pass it an mmap of the fb directly (which you can get via fbink_get_fb_pointer) to save a few copy ops. (I've only very very very quickly skimmed the fbdev driver & linuxfb port so far).
  • I am vaguely hoping there's a way to set the resolution & dpi at runtime, because compile time defines feel a bit clunky.

Input might be messy to handle properly (although I expect that to be much much much less of a concern on Kindle than on Kobo ;)).

commented

That would be awesome!

I managed to change this project: https://github.com/lvgl/lv_port_linux_frame_buffer

And now i have something that seems to respond.
The background is still black though, and the native kindle stuff comes in between. So how do i avoid that other applications still draw stuff? KOReader seems to manage this - but iv'e got no clue why.

commented

That's another kettle of fish I wouldn't bother with just yet[1], as the ultimate solution will depend on your use-case.

Right now, as long as you don't interact with the screen (which shouldn't be an issue for a PoC), the only thing that might interact with it would be the status bar (namely, the clock & battery icon).


  1. See the KOReader startup script for the insane amount of hoop jumping involved...
commented

So, here's my code modified code: https://github.com/cyclops1982/lv_port_linux_frame_buffer/tree/kindleport

I'm currently just using the fbdev_flush method that the lvgl framebuffer branch provides. The demo code should be a UI and it does render a little image, but the rest of the colours are not visible. Touch/mouse interaction seems to work, but the rest is not there.

As mentioned, the screen is completely black and i think that's because something is wrong when writing the framebuffer.

commented

Bitdepth is wrong ;). Like I initially said, LVGL doesn't appear to support grayscale, so you can't use its 8bpp support, as it's RGB332 and not grayscale (Y8). (Because Y8 @ 8bpp is the native (and sensible) format of the Kindle fb).

You've actually set it to 1bpp, which is even wronger ;).

I don't know if your device actually has a large enough framebuffer for RGB32 (it hasn't necessarily been a given on Basics and related devices), so you'll want to check that first manually via fbdepth & fbink.

At worst, you should be able to run at 16bpp, as the driver should indeed be expecting that to be RGB565 (... or BGR565, but that's a minor issue at this point, especially since the display will quantize to 16c grayscale anyway). Again, double-check that, as I'm not entirely sure that applies to Kindles.

Regardless, you will have to physicially modify the framebuffer status to a compatible "color" state (i.e., 32bpp or 16bpp) with fbink_set_fb_info like I mentioned earlier.

(And restore it on exit, because I remember Xorg being very very very upset about doing that behind its back. You might even have to actually deal with the whole mess I alluded to in my previous answer and drop the kindle's UI framework in order to be able to do that safely).

commented

Ha, i expected this thing to be so low, that i never tried 8 bits. That seems to work a lot better already. I have some interaction with the mouse, but it's still struggling a bit with the various colours and moving it to greyscale or whatever it needs to be.
i think i'll be able to work around that with a theme or so.

thanks for the comments on the code - will review them again later!

commented

RGB332 just isn't grayscale, it's as simple as that ;).