NiLuJe / FBInk

FrameBuffer eInker, a small tool & library to print text & images to an eInk Linux framebuffer
https://www.mobileread.com/forums/showthread.php?t=299110
GNU General Public License v3.0
332 stars 23 forks source link

How to use as library? #74

Open cyclops1982 opened 1 year ago

cyclops1982 commented 1 year ago

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?

NiLuJe commented 1 year ago

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?)

NiLuJe commented 1 year ago

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

NiLuJe commented 1 year ago

Small other random comments:

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 ;)).

cyclops1982 commented 1 year ago

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.

NiLuJe commented 1 year ago

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...
cyclops1982 commented 1 year ago

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.

NiLuJe commented 1 year ago

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).

cyclops1982 commented 1 year ago

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!

NiLuJe commented 1 year ago

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