Handle LVGL manually instead of using an internal task

[Maldus512]

Related area

LVGL port

Hardware specification

ESP32-P4

Is your feature request related to a problem?

I usually setup my projects with a single task that handles both low-latency IO and the UI with LVGL. Having a single task greatly simplifies data management.
The LVGL port component forces LVGL to run in an internal task with mutexes for synchronization. I wish to avoid that, calling lv_timer_handle and lv_tick_inc by myself while still leveraging other APIs like lvgl_port_add_disp_dsi.

Describe the solution you'd like

Adding a configuration parameter to avoid mutex synchronization calls like lvgl_port_lock, either as a CONFIG macro or a field in lvgl_port_cfg_t so that I can simply avoid initializing the port while still adding dsi displays and the like.

Describe alternatives you've considered

Right now I'm using the LVGL internal task as "main" task by creating a periodic LVGL task that also manages low-latency IO, but having the low level drivers depend on the UI isn't ideal.

Additional context

I'd be more than willing to work on a pull request but I'd like to know beforehand if such a feature would be welcome.

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.

[github-actions]

Hi @Maldus512! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Thank you for your detailed feature request and for describing your use case clearly.

Based on the available documentation and changelogs for the esp_lvgl_port component, there is currently no explicit support for running LVGL entirely in a user-managed task while still leveraging the port’s helper APIs (such as lvgl_port_add_disp_dsi) without the internal task and mutex synchronization. The current design of the esp_lvgl_port component is centered around managing LVGL in its own internal task, with mutexes required for thread safety when accessing LVGL APIs from other tasks. This is consistently documented in the usage guides and examples, which instruct users to use lvgl_port_lock/lvgl_port_unlock around LVGL calls to ensure thread safety, due to the internal task model LVGL ESP Portation Usage LVGL ESP Portation Usage.

There is no documented configuration parameter or macro in the current public releases or changelogs that allows disabling the internal LVGL task or mutex synchronization, nor a way to initialize only the helper APIs (like DSI display addition) without the full port initialization Changelog.

Your suggestion—to add a configuration option (via Kconfig or a field in lvgl_port_cfg_t) to allow advanced users to manage LVGL execution and synchronization themselves while still using the port’s display/input helpers—is not currently available, but it is a reasonable and well-motivated feature request.

Next steps:

• Since this feature does not exist yet, your proposal would be a valuable contribution, especially for advanced users with custom task architectures.
• The maintainers have not indicated opposition to such extensibility in the documentation, so opening a pull request or starting a discussion on the repository would be appropriate.
• You may want to highlight that this feature would be opt-in and targeted at advanced users who understand the risks of bypassing the internal synchronization.

Summary:
At present, the esp_lvgl_port component does not support bypassing its internal LVGL task and mutexes while still using its helper APIs. Your feature request is not currently addressed in the available documentation or changelogs, but it is a reasonable enhancement for advanced use cases.

If you need further details or want to discuss implementation ideas, the maintainers would likely appreciate your input and a pull request proposal.

---

References:

• LVGL ESP Portation Usage
• esp_lvgl_port Changelog
• LVGL ESP Portation Usage