Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use as library? #74

Open
cyclops1982 opened this issue May 2, 2023 · 9 comments
Open

How to use as library? #74

cyclops1982 opened this issue May 2, 2023 · 9 comments

Comments

@cyclops1982
Copy link

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
Copy link
Owner

NiLuJe commented May 3, 2023

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
Copy link
Owner

NiLuJe commented May 3, 2023

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

@NiLuJe
Copy link
Owner

NiLuJe commented May 3, 2023

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

@cyclops1982
Copy link
Author

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.

@cyclops1982 cyclops1982 reopened this May 5, 2023
@NiLuJe
Copy link
Owner

NiLuJe commented May 5, 2023

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
Copy link
Author

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
Copy link
Owner

NiLuJe commented May 5, 2023

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
Copy link
Author

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
Copy link
Owner

NiLuJe commented May 6, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants