apps/lvgl: upgrade to lvgl version v9

[XuNeo]

Summary

Dependson https://github.com/apache/nuttx/pull/11780

Limitations

1. Should wait LVGL to release v9.0.1 to fix existing issues firstly.
2. For now cmake only works with manually cloning lvgl to apps/graphics/lvgl/lvgl. cmake will generate error during source apps/graphics/lvgl/lvgl/Kconfig because it's not downloaded yet during config. Using make has no issue。

Impact

LVGL v8 and v9 is not compatible, it needs considerable work to porting to v9.

Testing

[XuNeo]

LVGL has released version v9.1.0. Locally tested and works.

I have to copy file content from lvgl/lvgl/Kconfig to lvgl/Kconfig because source lvgl/Kconfig won't work if the source haven't been downloaded yet. Use osource lvgl/Kconfig will not complain when executing tools/configure.sh but since the configuration is done without the lvgl Kconfig, it won't build either event it's downloaded later during make.

I have see no other options but to copy the Kconfig content to nuttx.

[xiaoxiang781216]

Yes, I think so:(, not perfect.

[TimJTi]

What about a script that pre-downloads the lvgl library? The main NuttX Kconfig lvgl entry could say that running the script is advisable and to re-run make menuconfig having done so? Or that having enabled the option to enable lvgl, a make should be followed by running the NuttX make menuconfig again? Seems a shame to have to copy a Kconfig file that could change with the next lvgl update?

[acassis]

What about a script that pre-downloads the lvgl library? The main NuttX Kconfig lvgl entry could say that running the script is advisable and to re-run make menuconfig having done so? Or that having enabled the option to enable lvgl, a make should be followed by running the NuttX make menuconfig again? Seems a shame to have to copy a Kconfig file that could change with the next lvgl update?

I think the idea of our build system is to automate things, if the user needs to run separated scripts, I see no point on our building system.

@XuNeo maybe we need to talk with @kisvegabor to help us to conciliate our Kconfig

[cederom]

I also thought about that and in a perfect situation we have all source code modules etc as part of repository do no additional downloads are necessary and everything should work out of the box in full offline mode..? :-)

[acassis]

I also thought about that and in a perfect situation we have all source code modules etc as part of repository do no additional downloads are necessary and everything should work out of the box in full offline mode..? :-)

Yes, I think we could have a "make download" to download all libraries to let user compile it online.

[cederom]

Yes, I think we could have a "make download" to download all libraries to let user compile it online.

This can be also achieved with git submodule if the code is in external git repo..?

Or just copy the sources to out repo and have all in one place?

[acassis]

@XuNeo I think this is a limitation of Kconfig (or the way our build system works), it is not dynamic. If we modify some Kconfig and don't run "make menuconfig" our .config will not be updated during the make command.

Maybe an alternative we could do it during the board config we run the lib download to extract the needed Kconfig before running the process config phase.

[acassis]

Yes, I think we could have a "make download" to download all libraries to let user compile it online.

This can be also achieved with git submodule if the code is in external git repo..?

Or just copy the sources to out repo and have all in one place?

Git submodules was discussed many times and the conclusion is that is generates more issues than benefits.

Yes, that idea of copying the files to some place before building could be nice. Actually yocto and others building systems have this option.

[cederom]

What about full copy of external library (i.e. LVGL) to our source tree so everything is always in one place and ready do build offline with no additional downloads? Would that be acceptable?

[acassis]

What about full copy of external library (i.e. LVGL) to our source tree so everything is always in one place and ready do build offline with no additional downloads? Would that be acceptable?

Hmm, should be nice to have an alternative to not penalize people that doesn't require these external libs (imagine the time to clone it when you are a bad internet connection).

Maybe we could put it in a reparated repository, i.e. https://github.com/nuttx/libs (yes using our not currently used nuttx github)

[cederom]

Right, keeping things minimal is important, additional repository with necessary libs seems best solution (either as nuttx/libs or apache/nuttx-libs), just to have all in one place, to clone burn to disk and be prepared for offline work :-)

[kisvegabor]

I'm not an expert on NuttX, so please forgive me the silly question: why don't you have the same issue with other 3rd party libraries used in NuttX? I think LVGL uses Kconfig in a rather standard way, which should be similar to other libs in this regard.

[acassis]

I'm not an expert on NuttX, so please forgive me the silly question: why don't you have the same issue with other 3rd party libraries used in NuttX? I think LVGL uses Kconfig in a rather standard way, which should be similar to other libs in this regard.

Hi @kisvegabor, the issue is because when "make menuconfig" runs it expects the Kconfig to exist with the options to let users to select it. This is a classic chicken/egg dilemma. I think we don't have issues with other libs because none of then uses Kconfig.

If Kconfig front-end was dynamic and let to run scripts when user just select a lib, we could download LVGL after user select he wants it, then the Kconfig from LVGL could be extracted and used inside menuconfig.

@XuNeo any update?

[xiaoxiang781216]

it's resolved internally by osource: https://docs.zephyrproject.org/latest/build/kconfig/extensions.html

[acassis]

it's resolved internally by osource: https://docs.zephyrproject.org/latest/build/kconfig/extensions.html

Interesting, but it doesn't solve all the issue, because the LVGL confirm only will show up to users after the tarball is downloaded. That only will happen in the building phase.

Also it is incompatible with kconfig-frontend (Kconflib has some issue, if you search for CONFIG_SYMBOL it will not find, you need to search only for SYMBOL, kconfig-frontend works with both).

@XuNeo maybe an alternative is just create an empty lvgl repository with only the Kconfig from LVGL 9.x, then before the tarball is decompressed we remove the fake lvgl and will be created again when the tarball is extracted.

[XuNeo]

maybe an alternative is just create an empty lvgl repository with only the Kconfig from LVGL 9.x

Unfortunately, I cannot find a better solution. Create an empty lvgl repository has same effect of copying out lvgl/lvgl/Kconfig to nuttx lvgl/Kconfig, which is current PR.

I suggest remove the LVGL version config option config LVGL_VERSION since it's tied to LVGL v9 now. If some folks still want LVGL v8, they must revert this commit.

[acassis]

maybe an alternative is just create an empty lvgl repository with only the Kconfig from LVGL 9.x

Unfortunately, I cannot find a better solution. Create an empty lvgl repository has same effect of copying out lvgl/lvgl/Kconfig to nuttx lvgl/Kconfig, which is current PR.

I suggest remove the LVGL version config option config LVGL_VERSION since it's tied to LVGL v9 now. If some folks still want LVGL v8, they must revert this commit.

Agree! Let's move to the new version!

[acassis]

@XuNeo another point: is it possible to integrate your lua+lvgl binding (https://github.com/XuNeo/luavgl) into nuttx-apps?

[XuNeo]

Hi, I have removed the config option to select different LVGL version. Now it's fixed to v9.1.0. Manually tested with https://github.com/apache/nuttx/pull/11780 on local Ubuntu 22.04 with Makefile and cmake to build boards/sim/sim/sim/configs/lvgl_fb. For cmake, need to config CONFIG_LV_TXT_BREAK_CHARS="".

@XuNeo another point: is it possible to integrate your lua+lvgl binding (https://github.com/XuNeo/luavgl) into nuttx-apps?

I'm still not happy with its current implementation that it needs manually work in order to add new widgets to support. LVGL v9 has introduced a new unified property API that may help a bit. It's kind of still ongoing. I hope I can optimize it further when get time.

[xiaoxiang781216]

@XuNeo please fix the nxstyle warning: https://github.com/apache/nuttx-apps/actions/runs/8849934321/job/24303028511?pr=2312