Open abrondijk opened 3 days ago
@abrondijk Thanks for looking into this - I've wanted to look into moving to v9, but haven't had the time to do so yet 😅
Regarding your idea - I think I prefer the template approach because I think that will keep the API cleaner and more strongly typed, while still allowing for support of both v8 and v9 should someone want to stay on v8.
@finger563 Ok, I'll start working on that!
As for being able to use both versions, the way to tie the framebuffers and the flush callbacks are a bit different. If you'd like to support both, I can probably work around it with macros.
@abrondijk Personally, I'd prefer to simply migrate to v9 (since that's what would be bundled with espp anyway) if that's the case.
Answers checklist.
General issue report
I'm working on migrating LVGL from v8 to v9 and I've run into some issues in regards to your
espp::Display
class.LVGL v9 no longer uses macro magic to populate the
lv_color_t
struct depending on the chosen color depth. Instead, it has different types for the different color depths, andlv_color_t
represents RGB888. This means thatlv_color_t
can no longer be the type of the framebuffers if the display in question uses the RGB565 format for example.Now this is all fine and can be implemented in the different display driver classes, but currently, the
espp::Display
class useslv_color_t
as well.The
vram
pointers can be void pointers (also what LVGL uses internally), but thevram_size_bytes()
function usessizeof(lv_color_t)
. Should theAllocatingConfig
and theNonAllocatingConfig
structs also have a member that holds the buffer size in bytes, like thepixel_buffer_size
? Or, perhaps a member that holds the amount of bytes per pixel?Additionally, I think that the
uint16_t *vram0()
anduint16_t *vram1()
functions should instead also be void pointers to support all color depths.Alternatively, the
espp::Display
class could be templated to indicate the pixel type, but that would be a rather large refactor.What are your thoughts?