Closed PGNetHun closed 5 months ago
Problem solved in other PR, and is merged to multi-instance
branch for multi-instance PR.
Tested on real ESP32 devices with ST7789 and ILI9342C displays.
I've raised some concerns about if we really need draw_buf
in lv_display_set_draw_buffers()
. Could you tell your opinion in https://github.com/lvgl/lvgl/pull/5204?
You are doing it right to use lv_draw_buf_init.
I see that there is also a lv_draw_buf_init() function, which accepts a void* memory area, but it tries to align it.
The issue is you have configured to do so.
I've raised some concerns about if we really need
draw_buf
inlv_display_set_draw_buffers()
. Could you tell your opinion in lvgl/lvgl#5204?
Let's open an new issue for it, so everyone can see it. Doing it now.
Hello @XuNeo, @kisvegabor ,
There is a buffer allocation issue in display initialization for ESP32 ili9xxx driver: https://github.com/lvgl/lv_binding_micropython/blob/master/driver/esp32/ili9XXX.py#L151
(ESP32 document about DMA-Capable memory allocation)
These 2 lines allocate memory which can be accessed by DMA, and returns
void *
, so a simple memory area, and it cannot be passed to lv_display_set_draw_buffers(lv_display_t disp, lv_draw_buf_t buf1, lv_draw_buf_t * buf2), which was refactored in this PR. Neither lv.draw_buf_create() will not allocate DMA-capable memory area.I see that there is also a lv_draw_buf_init() function, which accepts a
void*
memory area, but it tries to align it.Why do we need
lv_draw_buf_t
everywhere, even for display buffer (and decoded image data)? Only to have word-aligned memory area?Could you please check the above mentioned codes and help in this topic?