lvgl
Use VGLite in linux or other OS with MMU
Introduce the problem
In the src/draw directory, LVGL contains adaptation code related to VGLite. However, the issue lies in the fact that this codebase seems to be usable only on platforms without MMU enabled, such as baremetal. In contrast, on Linux or other OS that utilize MMU, the memory and address fields within the vg_lite_buffer_t structure are distinct. memory represents the CPU-mapped virtual address, while address corresponds to the physical address visible to the GPU. It is advisable to utilize vg_lite_allocate for allocating buffers intended for GPU use, instead of placing an arbitrary pointer in the vg_lite_buffer_t::memory field. Any suggestions for modifications?
Proposal
No response
I noticed that in the lv_vg_lite_buffer_init function, buffers with width = 16, height = 12, and format = VG_LITE_A8 are frequently allocated. What are these buffers used for?
Hi,
What kind of hardware do you use?
I noticed that in the lv_vg_lite_buffer_init function, buffers with width = 16, height = 12, and format = VG_LITE_A8 are frequently allocated. What are these buffers used for?
It's for letter drawing. A PR is already opened to eliminate it.
Hi,
What kind of hardware do you use?
I noticed that in the lv_vg_lite_buffer_init function, buffers with width = 16, height = 12, and format = VG_LITE_A8 are frequently allocated. What are these buffers used for?
It's for letter drawing. A PR is already opened to eliminate it.
kendryte K230.
I try to allocate a LV_MEM_SIZE buffer from vg_lite_allocate, and pass to LV_MEM_ADR, and calculate offset of physical address in lv_vg_lite_buffer_init , it works.
@MrThanlon
Consider connecting the memory allocation interface pair of lv_draw_buf to the vg_lite_allocate interface.
We need some feedback on this issue.
Now we mark this as "Abandoned" because there was no activity here for 14 days.
Remove the "Stale" label or comment else this will be closed in 7 days.
The VGLite API from the LVGL is a client API which communicates to the lower half API, composed by a Kernel Driver component that handles the GPU communication low level stuff, the SoC manufacturer is responsible to provide this kernel interface API.
For other parts like NXP processors, they provide a Linux like kernel driver.
You may reach the SoC manufacturer to check about the low level stuff for VGLite targeting its GPU.
Of course there is a possibility to bridge the VGLite client APi to the low level using the POSIX mmap() system calls to get the base address of the GPU device.
The VGLite API from the LVGL is a client API which communicates to the lower half API, composed by a Kernel Driver component that handles the GPU communication low level stuff, the SoC manufacturer is responsible to provide this kernel interface API.
For other parts like NXP processors, they provide a Linux like kernel driver.
You may reach the SoC manufacturer to check about the low level stuff for VGLite targeting its GPU.
Of course there is a possibility to bridge the VGLite client APi to the low level using the POSIX mmap() system calls to get the base address of the GPU device.
The kernel driver only provides memory allocation (mainly DMA memory allocator and dma-buf management) and the functionality to read and write GPU registers, the bridge is implemented by libvg_lite.so.
We need some feedback on this issue.
Now we mark this as "Abandoned" because there was no activity here for 14 days.
Remove the "Stale" label or comment else this will be closed in 7 days.
I'm wondering if the time of a more complete memory management module has arrived, the idea is not just allocating buffers but doing some sort of management using the host OS capabilities, in the future most of the OS env for MCU will be on top of trust zones while the MPUs will receive more and more capabilities, so allocation, mapping, and capabilities settings would be some of things that LVGL may handle by itself ( like frame buffers or mapping GPU register space on OS Like Linux, Windows or QNX)
We need some feedback on this issue.
Now we mark this as "Abandoned" because there was no activity here for 14 days.
Remove the "Stale" label or comment else this will be closed in 7 days.
As there was no activity here for a while we close this issue. But don't worry, the conversation is still here and you can get back to it at any time.
Feel free to comment if you have remarks or ideas on this topic.