[RC] LVGL 9.2.1 on NuttX 12.7.0(-RC) workbench.

[cederom]

Description / Steps to reproduce the issue

As reported during 12.7.0-RC0 testing:

@fjpanag:

I am stuck with stm32f746g-disco:lvgl configuration on a Discovery STM32F746 board, the screen displays garbage.
I start to suspect that this may be an issue with my board, rather than NuttX.

@TimJTi:

I have had lots of issues with LVGL 9.1 as used in NuttX, but on SAMA5D2. The framebuffer was being rendered to directly causing tearing. I have also seen LVGL repo issues relating to STM32, I think. LVGL V9.2 fixes my issues.
Don’t necessarily assume it’s a board fault!

On which OS does this issue occur?

[OS: BSD], [OS: Linux], [OS: Mac]

What is the version of your OS?

unknown

NuttX Version

12.7.0-RC0

Issue Architecture

[Arch: all]

Issue Area

[Area: Applications], [Area: Drivers]

Verification

• I have verified before submitting the report.

[raiden00pl]

probably related issue: #13839

[kisvegabor]

Could you add a photo of the broken screen? It could help a lot to identify the root of the issue.

[cederom]

Thanks @kisvegabor ! As reported by @raiden00pl : #13839.

Problems reported previously by @TimJTi seems to be already fixed and merged to LVGL upstream :-)

[cederom]

Update: This may not be the LVGL issue as reported here: #13839 (comment) :-)

If there is 9.2.1-RC0 then we may test all changes and fixes on a real hardware :-)

[kisvegabor]

Thank you! I can't see how LVGL could render this kind of pattern due to a misconfiguration on our end, so probably it's really a board issue.

[jerpelea]

lvgl/lvgl#6981 is merged

[jerpelea]

apache/nuttx-apps#2592 please test

[jerpelea]

apache/nuttx-apps#2670 backport

[cederom]

Awesome all issues seems fixed on NuttX side! BIG THANK YOU!! :-)

[jerpelea]

@cederom apache/nuttx-apps#2592 is not merged

[cederom]

LVGL 9.2.1 will be relased on 2024-10-14 then we can make final tests / tuning and merge.. thank you for the patience @jerpelea :-)

[jerpelea]

@cederom updates?

[cederom]

Thanks @jerpelea :-)

• There were performance regressions found right before 9.2.1 release was out so it is still not released as search for fix is ongoing.
• @kisvegabor yesterday created a discussion on LVGL 9.2.1 release: v9.2.1 Release Discussion lvgl/lvgl#7098.
• I will propose to create release/v9.2.1 branch so we are not blocked with our testing while fixes would be backported to that branch from master just as you do for 12.7.0 NuttX release :-)

[cederom]

• Okay I have asked on v9.2.1 Release Discussion lvgl/lvgl#7098 if the release/v9.2.1 branch could be created so we could move further with 9.2.1+12.7.0 integration.
• I know we are 3 weeks after planned NuttX 12.7.0 release date and quickly approaching 4th week. Sorry for that. I am the blocker but I thought LVGL was important feature to have.
• If release/v9.2.1 branch is not out until Sunday we may consider sticking with 9.1.0 not to delay more our release. Various framebuffer and LCD drivers problems are solved on our side. When 9.2.1 is ready and finished we may add it in 12.8.
• What do you think @jerpelea ? :-)

[TimJTi]

Is it feasible/possible to allow a choice of LVGL version via Kconfig?

I know there is a copy/paste of the LVGL Kconfig content to the NuttX one which is a fudge, but I am not experienced enough with Kconfig syntax to know if the archive file path can be constructed from the user choice so the correct file will be downloaded?

I've seen an argument here that we don't want to have to have a 2 stage process (select LVGL, then execute a make to get the archive loaded and only then are the correct Kconfig settings available) but surely there's a way around this?

I'm not working today but I will try and research this as a possibility over the weekend.

[cederom]

Okay, so the LVGL releases/v9.2 branch is here and this is our target branch to work on 99% ready before the 9.2.1 release (there are no patch release branches) :-)

https://github.com/lvgl/lvgl/tree/release/v9.2

As LVGL tag v9.2.1 is not here yet we may use branch v9.2 code for testing its 99% 9.2.1 :-)

https://github.com/lvgl/lvgl/archive/refs/heads/release/v9.2.zip

[TimJTi]

Is it feasible/possible to allow a choice of LVGL version via Kconfig?

I know there is a copy/paste of the LVGL Kconfig content to the NuttX one which is a fudge, but I am not experienced enough with Kconfig syntax to know if the archive file path can be constructed from the user choice so the correct file will be downloaded?

I've seen an argument here that we don't want to have to have a 2 stage process (select LVGL, then execute a make to get the archive loaded and only then are the correct Kconfig settings available) but surely there's a way around this?

I'm not working today but I will try and research this as a possibility over the weekend.

I tracked down the original discussion thread from the mail archive here and had a look around for clever "tricks". Sadly I have to conclude that we have little choice but to do the copy/paste of LVGL's Kconfig contents when there's an LVGL upgrade:

1. Kconfig doesn't execute any "code" as such so it can't go and grab the required LVGL Kconfig file on the fly.
2. I couldn't see a way for kconfig to reference a URL
3. Even if it could, it would need an internet connection which I gather should not be a "requirement" for this to allow offline working (does anyone these days LOL)
4. kconfiglib might give more options as it could execute python code (not anything I have experience of) if I understand it right. But that's not what we use.
5. Even if we "revert" and allow the version of LVGL to be used (as it used to be) it falls over for most of the above reasons.
6. LVGL "Master" doesn't ever exist as a downloadable archive/tarball so we can't even offer that...and most of the above applies too!

Guess we will stick withe what we've got - but I will do a small documentation PR to add a "how to" to explain how to use a different LVGL version by cloning the LVGL repo directly into your own nuttx-apps space and copy/pasting the LVCGL Kconfig to NuttX's local copy.

[cederom]

TLDR: Its a nice idea to support several LVGL versions in NuttX, but its out of scope of this PR where we want to have specifically 9.2.1 in 12.7.0, we should talk about that in a separate Issue not to mix too many things in one place?

@TimJTi: Is it feasible/possible to allow a choice of LVGL version via Kconfig?
I know there is a copy/paste of the LVGL Kconfig content to the NuttX one which is a fudge, but I am not experienced enough with Kconfig syntax to know if the archive file path can be constructed from the user choice so the correct file will be downloaded?
I've seen an argument here that we don't want to have to have a 2 stage process (select LVGL, then execute a make to get the archive loaded and only then are the correct Kconfig settings available) but surely there's a way around this?
I'm not working today but I will try and research this as a possibility over the weekend.

@TimJTi: I tracked down the original discussion thread from the mail archive here and had a look around for clever "tricks". Sadly I have to conclude that we have little choice but to do the copy/paste of LVGL's Kconfig contents when there's an LVGL upgrade:

Thanks @TimJTi :-) Another approach would be to keep different LVGL releases in separate directories and reference them with a different configurations? Then process them with Make/CMake just as we do with external packages that are then patched before use in NuttX?

1. Kconfig doesn't execute any "code" as such so it can't go and grab the required LVGL Kconfig file on the fly.

This may be a good design goal. This tool is only for configuration. Make/CMake is for processing the configuration.

2. I couldn't see a way for kconfig to reference a URL

By assigning a configuration string variable as URL or directory location holding specific LVGL version?

3. Even if it could, it would need an internet connection which I gather should not be a "requirement" for this to allow offline working (does anyone these days LOL)

4. kconfiglib might give more options as it could execute python code (not anything I have experience of) if I understand it right. But that's not what we use.

Again its not Kconfig task to perform operations, its only for configuration :-)

5. Even if we "revert" and allow the version of LVGL to be used (as it used to be) it falls over for most of the above reasons.

This may be treated as "just onother different configuration"?

6. LVGL "Master" doesn't ever exist as a downloadable archive/tarball so we can't even offer that...and most of the above applies too!

I think it does, look:

• Official release: https://github.com/lvgl/lvgl/archive/refs/tags/v9.2.0.tar.gz
• Release branch archive: https://github.com/lvgl/lvgl/archive/refs/heads/release/v9.2.zip
• Master package: https://github.com/lvgl/lvgl/archive/refs/heads/master.tar.gz

We should stick to releases in the first place. Now its a "special" situation where we want to test stuff right before a release so we use release branch package, but we will switch this variable to a release package again as soon as it shows up.

But having a dedicated lvgl git master port may be good for testing, it should be possible to use lvgl master too, and you may call this port "lvgl-devel" to align with other OS nomenclature :-)

Guess we will stick withe what we've got - but I will do a small documentation PR to add a "how to" to explain how to use a different LVGL version by cloning the LVGL repo directly into your own nuttx-apps space and copy/pasting the LVCGL Kconfig to NuttX's local copy.

Some better process is required here. You may take a look at FreeBSD ports how things are done [1] as an example the process is similar in NuttX. There are various "ports" where the same program/library may exist in different versions (mutually exclusive, i.e. mysql, python, qt, etc). We may have different LVGL applications / system libraries here too for different LVGL versions. Also note the standard steps like "fetch" as the first step where connections are possible, then "extract", "patch", "configure", "build", "stage" (move binaries from src package to dedicated OS layout compliant prefix), "package" (create system package out of stage location), "install" - all this makes process clean and repeatable for all ports.

[1] https://docs.freebsd.org/en/books/porters-handbook/slow-porting

[jerpelea]

fix apache/nuttx-apps#2764

[jerpelea]

• Okay I have asked on v9.2.1 Release Discussion lvgl/lvgl#7098 if the release/v9.2.1 branch could be created so we could move further with 9.2.1+12.7.0 integration.

  • I know we are 3 weeks after planned NuttX 12.7.0 release date and quickly approaching 4th week. Sorry for that. I am the blocker but I thought LVGL was important feature to have.

  • If release/v9.2.1 branch is not out until Sunday we may consider sticking with 9.1.0 not to delay more our release. Various framebuffer and LCD drivers problems are solved on our side. When 9.2.1 is ready and finished we may add it in 12.8.

  • What do you think @jerpelea ? :-)

Sounds like a good plan
Let's hope LVGL will release on time

[cederom]

Looks like we are set on our side, all tested, waiting for LVGL 9.2.1 release to update the release URL, it should show up in days :-)

nop nop nop :-)

[cederom]

LVGL 9.2.1 release is planned for tomorrow :-)

[cederom]

As promissed LVGL 9.2.1 is out! :-)
https://github.com/lvgl/lvgl/archive/refs/tags/v9.2.1.zip
https://github.com/lvgl/lvgl/archive/refs/tags/v9.2.1.tar.gz

[kisvegabor]

Sorry guys, please take a look at this comment.

[cederom]

Thanks @kisvegabor :-) I think we use our own configuration mechanism that is not affected, did reply in lvgl/lvgl#7098 and waiting for @XuNeo confirmation, but I think all if fine on our side :-)

[kisvegabor]

Huh, great! I hope @XuNeo will confirm that it's okay.

[XuNeo]

nuttx have no such issue.

The Kconfig file content is copied out to nuttx-apps.
The last minute changes in LVGL's Kconfig is not updated in nuttx-apps.

diff --git a/graphics/lvgl/Kconfig b/graphics/lvgl/Kconfig
index 4daf467f3..620b3f41c 100644
--- a/graphics/lvgl/Kconfig
+++ b/graphics/lvgl/Kconfig
@@ -385,8 +385,18 @@ menu "LVGL configuration"
                        depends on LV_USE_DRAW_VGLITE
                        default n

+               config LV_USE_PXP
+               bool "Use NXP's PXP on iMX RTxxx platforms"
+               default n
+
                config LV_USE_DRAW_PXP
-                       bool "Use NXP's PXP on iMX RTxxx platforms"
+               bool "Use PXP for drawing"
+                       depends on LV_USE_PXP
+                       default y
+
+               config LV_USE_ROTATE_PXP
+                       bool "Use PXP to rotate display"
+                       depends on LV_USE_PXP
                        default n

                config LV_USE_PXP_DRAW_THREAD
@@ -730,6 +740,18 @@ menu "LVGL configuration"
                        int "Required alignment size for buffers"
                        default 1

+               config LV_ATTRIBUTE_MEM_ALIGN
+                       string "Will be added where memories needs to be aligned (with -Os data might not be aligned to boundary by default)."
+                       default ""
+                       help
+                               E.g. __attribute__((aligned(LV_ATTRIBUTE_MEM_ALIGN_SIZE)))
+
+               config LV_ATTRIBUTE_LARGE_CONST
+                       string "Attribute to mark large constant arrays for example font's bitmaps"
+                       default ""
+                       help
+                               E.g. __attribute__((section("DataQuickAccess")))
+
                config LV_ATTRIBUTE_FAST_MEM_USE_IRAM
                        bool "Set IRAM as LV_ATTRIBUTE_FAST_MEM"
                        help
@@ -1349,6 +1371,13 @@ menu "LVGL configuration"
                        bool "Enable system monitor component"
                        default n

+               config LV_SYSMON_GET_IDLE
+                       string "Get the idle percentage."
+                       depends on LV_USE_SYSMON
+                       default "lv_timer_get_idle"
+                       help
+                               E.g. uint32_t my_get_idle(void);
+
                config LV_USE_PERF_MONITOR
                        bool "Show CPU usage and FPS count"
                        depends on LV_USE_SYSMON

The newly added config option should be used similar to LV_PROFILER_BEGIN macro.

https://github.com/apache/nuttx-apps/blob/1506c6f54dcf6f969e3e8e4e2fed805bfac0b4a1/graphics/lvgl/Makefile#L38-L44