Display buffer initialization for ESP32

[PGNetHun]

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

self.buf1 = esp.heap_caps_malloc(self.buf_size, esp.MALLOC_CAP.DMA)
self.buf2 = esp.heap_caps_malloc(self.buf_size, esp.MALLOC_CAP.DMA) if double_buffer else None

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

[PGNetHun]

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.

[kisvegabor]

I've raised some concerns about if we really need draw_buf in lv_display_set_draw_buffers(). Could you tell your opinion in lvgl/lvgl#5204?

[XuNeo]

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.

https://github.com/lvgl/lv_binding_micropython/pull/314/files#diff-136397af91c41d3e65b59f16b7ae542b5545b37c353bd10417bdef6075be5821R82-R83

[XuNeo]

I've raised some concerns about if we really need draw_buf in lv_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.