graphics/lvgl: Upgrade LVGL to v9.4.0 #3253

terry0012 · 2025-12-17T09:07:18Z

Note: Please adhere to Contributing Guidelines.

Summary

Update CMakeLists.txt to use LVGL v9.4.0
Update Kconfig with new v9.4.0 configuration options
Update Makefile with new LVGL version

Impact

LVGL

Testing

test with rv-virt:lvgl64_vector created by another PR in nuttx repo (apache/nuttx#17532)

Verified LVGL demo

simbit18 · 2025-12-18T10:50:40Z

@terry0012 Question:

After this bump, will it be possible to use previous versions of LVGL (v9.2.1) ?

It might be useful to choose the version and allow compatibility with older versions.

linguini1

Can you please include the results of your test?

terry0012 · 2025-12-23T13:42:00Z

@terry0012 Question:

After this bump, will it be possible to use previous versions of LVGL (v9.2.1) ?

It might be useful to choose the version and allow compatibility with older versions.

after this bump，we can not use v9.2.1 version

terry0012 · 2025-12-23T13:44:27Z

Can you please include the results of your test?

Which test results would you like to see, and could you provide the test cases for lvgl?
lvgl example，unit test or others.

acassis

@terry0012 please include a comment about the LVGL version supported on NuttX:
https://nuttx.apache.org/docs/latest/applications/graphics/lvgl/index.html

linguini1 · 2025-12-23T16:33:58Z

Which test results would you like to see, and could you provide the test cases for lvgl?
lvgl example，unit test or others.

I don't know of any NuttX unit tests for lvgl, but I meant your test on rv-virt:lvgl64_vector. What was tested and what was the result?

terry0012 · 2025-12-27T00:56:31Z

Which test results would you like to see, and could you provide the test cases for lvgl?
lvgl example，unit test or others.

I don't know of any NuttX unit tests for lvgl, but I meant your test on rv-virt:lvgl64_vector. What was tested and what was the result?

lvgldemo is tested and running very well.

Let me explain why need to upgraded to 9.4 with rv-virt:lvgl64_vector:

On the QEMU emulator, input device virtio-mouse-device is recognized as a mouse device on NuttX, but LVGL 9.2 does not support mouse functionality in the NuttX porting layer.

I think what we should consider is @simbit18's opinion: whether upgrading LVGL will have side effects for users, and whether we need to support the capability for two versions.

@acassis Once the above issues are clarified, I will update the version information in the document.

xiaoxiang781216 · 2025-12-27T03:35:13Z

@terry0012 Question:
After this bump, will it be possible to use previous versions of LVGL (v9.2.1) ?
It might be useful to choose the version and allow compatibility with older versions.

after this bump，we can not use v9.2.1 version

you can revert this patch anyway. lvgl is a complex project keeping the backward comaptability isn't a simple task. Xaiomi has no plan to invest any resource on this direction. So, the option is either accept the patch or close it directly. @simbit18 @linguini1 @acassis .

LVGL demo verified

simbit18 · 2025-12-29T10:17:57Z

@xiaoxiang781216 , it is important to let the community know that only version 9.4 of LVGL will be usable. Perhaps someone in the community will be able to devote some time to developing a multi-version solution for LVGL.

there is an error

====================================================================================
Configuration/Tool: lckfb-szpi-esp32s3/lvgl
2025-12-17 10:12:51
------------------------------------------------------------------------------------
  Cleaning...
  Configuring...
  Building NuttX...
In file included from /github/workspace/sources/apps/graphics/lvgl/lvgl/src/drivers/lv_drivers.h:32,
                 from /github/workspace/sources/apps/graphics/lvgl/lvgl/lvgl.h:134,
                 from lvgldemo.c:31:
Error: /github/workspace/sources/apps/graphics/lvgl/lvgl/src/drivers/display/st7789/lv_st7789.h:31:9: error: unknown type name 'lv_lcd_send_cmd_cb_t'
   31 | typedef lv_lcd_send_cmd_cb_t lv_st7789_send_cmd_cb_t;
      |         ^~~~~~~~~~~~~~~~~~~~
Error: /github/workspace/sources/apps/graphics/lvgl/lvgl/src/drivers/display/st7789/lv_st7789.h:32:9: error: unknown type name 'lv_lcd_send_color_cb_t'
   32 | typedef lv_lcd_send_color_cb_t lv_st7789_send_color_cb_t;
      |         ^~~~~~~~~~~~~~~~~~~~~~
Error: /github/workspace/sources/apps/graphics/lvgl/lvgl/src/drivers/display/st7789/lv_st7789.h:47:69: error: unknown type name 'lv_lcd_flag_t'; did you mean 'lv_obj_flag_t'?
   47 | lv_display_t * lv_st7789_create(uint32_t hor_res, uint32_t ver_res, lv_lcd_flag_t flags,
      |                                                                     ^~~~~~~~~~~~~
      |                                                                     lv_obj_flag_t

xiaoxiang781216 · 2025-12-29T11:21:34Z

@terry0012 please fix the build error

cederom

Thank you @terry0012 :-)

Hmm there are number of users of LVGL 9.2.1 and some demos for various boards. We cannot break stuff for them.
This is a potential breaking change. Brings fixes/improvements but require some announcement on the mailing (will write one) list and testing.
I thought LVGL was supposed (announced) to be self-compatible among three (?) major release numbers?
Is the backward compatibility broken because of lvgl internals or the implementation of this change?

terry0012 · 2025-12-29T13:42:07Z

@xiaoxiang781216 , it is important to let the community know that only version 9.4 of LVGL will be usable. Perhaps someone in the community will be able to devote some time to developing a multi-version solution for LVGL.

there is an error

====================================================================================
Configuration/Tool: lckfb-szpi-esp32s3/lvgl
2025-12-17 10:12:51
------------------------------------------------------------------------------------
  Cleaning...
  Configuring...
  Building NuttX...
In file included from /github/workspace/sources/apps/graphics/lvgl/lvgl/src/drivers/lv_drivers.h:32,
                 from /github/workspace/sources/apps/graphics/lvgl/lvgl/lvgl.h:134,
                 from lvgldemo.c:31:
Error: /github/workspace/sources/apps/graphics/lvgl/lvgl/src/drivers/display/st7789/lv_st7789.h:31:9: error: unknown type name 'lv_lcd_send_cmd_cb_t'
   31 | typedef lv_lcd_send_cmd_cb_t lv_st7789_send_cmd_cb_t;
      |         ^~~~~~~~~~~~~~~~~~~~
Error: /github/workspace/sources/apps/graphics/lvgl/lvgl/src/drivers/display/st7789/lv_st7789.h:32:9: error: unknown type name 'lv_lcd_send_color_cb_t'
   32 | typedef lv_lcd_send_color_cb_t lv_st7789_send_color_cb_t;
      |         ^~~~~~~~~~~~~~~~~~~~~~
Error: /github/workspace/sources/apps/graphics/lvgl/lvgl/src/drivers/display/st7789/lv_st7789.h:47:69: error: unknown type name 'lv_lcd_flag_t'; did you mean 'lv_obj_flag_t'?
   47 | lv_display_t * lv_st7789_create(uint32_t hor_res, uint32_t ver_res, lv_lcd_flag_t flags,
      |                                                                     ^~~~~~~~~~~~~
      |                                                                     lv_obj_flag_t

@cederom @simbit18
In lvgl v9.4.0 and master branch, the config LV_USE_GENERIC_MIPI is changed to depends on Kconfig, but not lvgl internal config (https://github.com/lvgl/lvgl/blob/e9db313f8ccc07e27f6afd0f34fe3cf6f20596f0/src/lv_conf_internal.h#L4336C1-L4356C7)

In lvgl v9.2.0, LV_USE_GENERIC_MIPI is auto selected by lv internal config as https://github.com/lvgl/lvgl/blob/6757a718a88af58591c90f5ab33ca2770606c314/src/lv_conf_internal.h#L3455-L3461

we need to change the Kconfig to auto select LV_USE_GENERIC_MIPI if ST7789 enabled.
I'll fix the bug in Kconfig and upstream to LVGL community too.
CC @xiaoxiang781216

- Update CMakeLists.txt to use LVGL v9.4.0 - Update Kconfig with new v9.4.0 configuration options - Update Makefile with new LVGL version Signed-off-by: rongyichang <rongyichang@xiaomi.com>

TimJTi · 2025-12-29T14:08:15Z

I have been using V9.4 + NuttX for a few months without issue.

The version used by NuttX has been discussed before and the current methodology (copy/paste lvgl Kconfig into NuttX Kconfig) has been vigourously defended in the past so as to avoid a two stage make process: if the version were to be selected via NuttX Kconfig, the download won't happen until you run make...and the LVGL Kconfig from within NuttX is then not available until after the make...so it's a 2 stage process.

It doesn't mean users can't use earlier versions if the default becomes V9.4 for NuttX though. It becomes a manual process to clone the LVGL repo of the required LVGL version over the top of the default NuttX automated download, and then copy/paste the Kconfig from LVGL to NuttX. This is not overridden ny NuttX, once the LVGL repo exists as a cloned copy.

9.2.1 to 9.4 is unlikely to break much from memory - it is when the major version changes that things are more likely to break. I think!

But surely it would be possible to include support for both 9.2.1 and 9.4 wouldn't it? Both sets of LVGL Kconfig options could pre-exist within the NuttX Kconfig, with the right set chosen via Nuttx Kconfig choice, which then determines which LVGL version is downloaded?

Maybe we could always try and support latest and "last known good" LVGL versions as a matter of course by this method?

TimJTi · 2025-12-29T14:13:33Z

Maybe we could always try and support latest and "last known good" LVGL versions as a matter of course by this method?

Or...

Default is 9.4 with the pre-copied LVGL Kconfig, but an option for a manually-entered LVGL version. If manually entered, it becomes a two-stage process (with suitable warnings in Kconfig!!) to allow the version to be downloaded and only then do the LVGL Kconfig options become available within Nuttx, either by a script to copy them over, or direct reference (if that can be done?).

cederom

This looks like a simple version bump, according to upstream documentation it should be backward compatible [1]. I have started a mailing list thread asking for feedback. If there are some issues with the new release that are NuttX specific we should fix them on the NuttX side :-)

Hopefully soon I will play a bit with LVGL myself on the new board :-)

Thank you @TimJTi for your feedback, looks like revert to 9.2.1 just in case should be trivial :-)

Looking at the git files history related to lvgl do you see any important issues @XuNeo @HongChao6 @FASTSHIFT @gustavonihei @no1wudi @anchao @Cynerd @Ouss4 @protobits @Gary-Hobson @w8jcik @raiden00pl @Jasinsky @xuxin930 @Junbo-Zheng ?

[1] https://docs.lvgl.io/9.4/intro/introduction/repo.html#release-policy

terry0012 · 2025-12-30T01:59:41Z

This looks like a simple version bump, according to upstream documentation it should be backward compatible [1]. I have started a mailing list thread asking for feedback. If there are some issues with the new release that are NuttX specific we should fix them on the NuttX side :-)

Hopefully soon I will play a bit with LVGL myself on the new board :-)

Thank you @TimJTi for your feedback, looks like revert to 9.2.1 just in case should be trivial :-)

Looking at the git files history related to lvgl do you see any important issues @XuNeo @HongChao6 @FASTSHIFT @gustavonihei @no1wudi @anchao @Cynerd @Ouss4 @protobits @Gary-Hobson @w8jcik @raiden00pl @Jasinsky @xuxin930 @Junbo-Zheng ?

[1] https://docs.lvgl.io/9.4/intro/introduction/repo.html#release-policy

@cederom @simbit18

I got a lckfb-szpi-esp32s3 and test lvgldemo with LVGL v9.4.0.
Unfortunately, I ran into a crash. --!

It seems we need to check whether there are any issues when using LVGL v9.4.0, it may break stuff for those boards use LVGL.

terry0012 · 2025-12-30T10:36:22Z

This looks like a simple version bump, according to upstream documentation it should be backward compatible [1]. I have started a mailing list thread asking for feedback. If there are some issues with the new release that are NuttX specific we should fix them on the NuttX side :-)
Hopefully soon I will play a bit with LVGL myself on the new board :-)
Thank you @TimJTi for your feedback, looks like revert to 9.2.1 just in case should be trivial :-)
Looking at the git files history related to lvgl do you see any important issues @XuNeo @HongChao6 @FASTSHIFT @gustavonihei @no1wudi @anchao @Cynerd @Ouss4 @protobits @Gary-Hobson @w8jcik @raiden00pl @Jasinsky @xuxin930 @Junbo-Zheng ?
[1] https://docs.lvgl.io/9.4/intro/introduction/repo.html#release-policy

@cederom @simbit18

I got a lckfb-szpi-esp32s3 and test lvgldemo with LVGL v9.4.0. Unfortunately, I ran into a crash. --!

It seems we need to check whether there are any issues when using LVGL v9.4.0, it may break stuff for those boards use LVGL.

The reason for this problem is that the default stack space of lvgldemo is 16K, which is too small on V9.4 and causes stack overflow. Expanding it to 64K allows it to run normally.

But when I enable CONFIG_STACK_COLORATION, I found that the stack usage is only 6K, I think stack size is not the root cause.

I need to use gdb to find more info. --!

terry0012 · 2025-12-31T12:19:21Z

@cederom @simbit18
In the end, I found the root cause of the crash. --!

In LVGL v9.4.0, the bitmap drawbuf will call up_flush_dcache(start, end); to sync the dcache.
But there is a bug in the implementation of up_flush_dcache (arch/xtensa/src/esp32s3/esp32s3_cache.c) which will cause application data corruption.
See apache/nuttx#17753

acassis · 2025-12-31T12:52:39Z

@fdcavalcanti @tmedicci @eren-terzioglu please take a look

cederom · 2025-12-31T14:21:41Z

@terry0012: I got a lckfb-szpi-esp32s3 and test lvgldemo with LVGL v9.4.0. Unfortunately, I ran into a crash. --!
It seems we need to check whether there are any issues when using LVGL v9.4.0, it may break stuff for those boards use LVGL.

@terry0012: The reason for this problem is that the default stack space of lvgldemo is 16K, which is too small on V9.4 and causes stack overflow. Expanding it to 64K allows it to run normally.

But when I enable CONFIG_STACK_COLORATION, I found that the stack usage is only 6K, I think stack size is not the root cause.

I need to use gdb to find more info. --!

Thank you @terry0012 :-) Looks like you already found the issue source in the ESP32 implementation right?

I just wanted to comment that current 6K stack is okay for small systems while 64K would not and we should stick to the lowest possible value (i.e. 32K RAM MCUs) :-)

terry0012 mentioned this pull request Dec 17, 2025

boards/risc-v: Add lvgl64_vector configuration for RISC-V QEMU apache/nuttx#17532

Merged

github-actions bot added Area: Graphics Size: L labels Dec 17, 2025

terry0012 force-pushed the lvgl branch 2 times, most recently from 264f938 to 4c9320f Compare December 17, 2025 09:10

simbit18 requested review from acassis, cederom, jerpelea, linguini1 and raiden00pl December 18, 2025 10:51

linguini1 previously requested changes Dec 18, 2025

View reviewed changes

acassis reviewed Dec 23, 2025

View reviewed changes

cederom requested changes Dec 29, 2025

View reviewed changes

graphics/lvgl: Upgrade LVGL to v9.4.0

313f45e

- Update CMakeLists.txt to use LVGL v9.4.0 - Update Kconfig with new v9.4.0 configuration options - Update Makefile with new LVGL version Signed-off-by: rongyichang <rongyichang@xiaomi.com>

terry0012 force-pushed the lvgl branch from 4c9320f to 313f45e Compare December 29, 2025 13:49

terry0012 mentioned this pull request Dec 29, 2025

build(Kconfig): auto select LV_USE_GENERIC_MIPI lvgl/lvgl#9491

Merged

xiaoxiang781216 requested a review from cederom December 29, 2025 14:36

cederom approved these changes Dec 29, 2025

View reviewed changes

anchao approved these changes Dec 30, 2025

View reviewed changes

terry0012 mentioned this pull request Dec 31, 2025

xtensa/esp32s3: fix dcache flush error in up_flush_dcache apache/nuttx#17753

Open

graphics/lvgl: Upgrade LVGL to v9.4.0 #3253

Are you sure you want to change the base?

graphics/lvgl: Upgrade LVGL to v9.4.0 #3253

Conversation

terry0012 commented Dec 17, 2025 • edited by linguini1 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Impact

Testing

Uh oh!

simbit18 commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linguini1 left a comment

Choose a reason for hiding this comment

Uh oh!

terry0012 commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

terry0012 commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

acassis left a comment

Choose a reason for hiding this comment

Uh oh!

linguini1 commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

terry0012 commented Dec 27, 2025

Uh oh!

xiaoxiang781216 commented Dec 27, 2025

Uh oh!

simbit18 commented Dec 29, 2025

Uh oh!

xiaoxiang781216 commented Dec 29, 2025

Uh oh!

cederom left a comment

Choose a reason for hiding this comment

Uh oh!

terry0012 commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TimJTi commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TimJTi commented Dec 29, 2025

Uh oh!

cederom left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

terry0012 commented Dec 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

terry0012 commented Dec 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

terry0012 commented Dec 31, 2025

Uh oh!

acassis commented Dec 31, 2025

Uh oh!

cederom commented Dec 31, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

terry0012 commented Dec 17, 2025 •

edited by linguini1

Loading

simbit18 commented Dec 18, 2025 •

edited

Loading

terry0012 commented Dec 23, 2025 •

edited

Loading

terry0012 commented Dec 23, 2025 •

edited

Loading

linguini1 commented Dec 23, 2025 •

edited

Loading

terry0012 commented Dec 29, 2025 •

edited

Loading

TimJTi commented Dec 29, 2025 •

edited

Loading

cederom left a comment •

edited

Loading

terry0012 commented Dec 30, 2025 •

edited

Loading

terry0012 commented Dec 30, 2025 •

edited

Loading