Suggestion for LVGL support (BSP-550)

[ammaree]

Related area

LVGL Display support

Hardware specification

ESP_WROVER_KIT and ESP32_S3_LCD_EV

Is your feature request related to a problem?

We are trying to optimise performance and reduce code footprint, flash and SRAM. In order to do this we have come across multiple challenges, such as :
*lvgl_port_task() support for index/touch device is forced but ESP_WROVER_KIT does not have a touch capability and in many cases buttons are not needed/used.
*Although we have access to a 1mSec resolution timer, we cannot disable the lvgl_port_tick_init() support completely.
*Trying to avoid the use of bsp_display_start_with_config, lvgl_port_task() and suchlike by duplicating the minimal functions required is also not possible since lvgl_port_ctx is declared static and many(most) APIs require this structure.
*In lvgl_port_task() the taskname has a space that breaks syslog functionality where, if the taskname is used in HOSTNAME, APP-NAME or PROCID fields, SP is interpreted as a separator hence 1 parameter becomes 2.

Describe the solution you'd like

The ultimate solution would be if the BSP, and especially LVGL support, was structured in a way that allows the individual components.
*Ideal would be through a list of macros being used to in/exclude sections of functionality, configured through menuconfig.
*Possible through a more comprehensive cfg structure where a member, say TaskInitFunc, can be initialised with a pointer to the task init function, if not provided the default is used. Similarly a member TaskTickHdlr overriding the tick support.

Describe alternatives you've considered

Have tried building own bsp_display_start() and lvgl_port_task() functionality, but failed due to close coupling and private nature of many/most BSP components

Additional context

No response

I have checked existing list of Feature requests and the Contribution Guide

• I confirm I have checked existing list of Feature requests and Contribution Guide.

[tore-espressif]

@espzav ICYMI :)

[espzav]

Hello @ammaree, this is a really complex question/issue. We are usually making lot of APIs settable at runtime instead of lot of ifdefs. I understand, that lot of code are unused, but it is not called, when not needed. We are still improving performance of the LVGL port component and BSP too.

The BSP and LVGL port should help to make it easier for customers and help with performance as possible as it. We understand that for some cases it can be hard to use. You can still use only LVGL port without BSP or only LVGL component without other Espressif's helpers.

In lvgl_port_task() the taskname has a space that breaks syslog functionality where, if the taskname is used in HOSTNAME, APP-NAME or PROCID fields, SP is interpreted as a separator hence 1 parameter becomes 2.

This is possible to change.

[ammaree]

Other than a) forking (with inherent problems of keeping up) or b) permanent ongoing patching of latest repo we seem to have no options.

In order to optimise use of the existing code BSP and LVGL port code and minimise the effort required to adapt functionality, it is only required for all/most enumerations, structure and variables to be public. This would allow us the wrap (replace) the minimum APIs thus adding functionality to our requirements.

Alternatively, as a serious compromise, we have identified a couple of small changes that will make operation a lot easier:

1. hook to specify API replacement for lvgl_port_ctx.running to trigger task shutdown externally
2. changing task name "LVGL task" to "taskLVGL" for consistency.

If we thing of anything more, will update but if possible making structures variables and APIs public would be ideal.

Thanks

[igrr]

Just 2c, note that IDF build system allows overriding components — whether built-in or managed ones. So you can override just esp_lvgl_port, and still use BSP components from the registry.

The way this would work would be:

1. Add a dependency on the specific BSP to your idf_component.yml
2. Download esp_lvgl_port component into <project>/components/esp_lvgl_port
3. Make modifications to esp_lvgl_port

When you build the project, BSP component will be downloaded, but for esp_lvgl_port dependency the build system will use your local version.

(This is just a slightly simpler workflow for keeping a fork without having to fork all the components; of course, we should still improve esp_lvgl_port so that maintaining the local version wouldn't be necessary.)

[klaatu2a]

Do you have the ESP32_S3_LCD_EV_BOARD running on LVGL 9.2.2?
If so, what changes were necessary?

[espzav]

Hi @klaatu2a, we have ESP32_S3_LCD_EV_BOARD in BSP repository running with LVGL 9.2.2.