lvgl: Update to 9.4.X

[faxe1008]

Forward the master branch to the current master HEAD to resolve some issues regarding DMA2D.

[github-actions]

Hi 👋, thank you for your PR!

We've run benchmarks in an emulated environment. Here are the results:

ARM Emulated 32b - lv_conf_perf32b

Scene Name	Avg CPU (%)	Avg FPS	Avg Time (ms)	Render Time (ms)	Flush Time (ms)
All scenes avg.	29 (+1)	37	7	7	0

Detailed Results Per Scene

Scene Name	Avg CPU (%)	Avg FPS	Avg Time (ms)	Render Time (ms)	Flush Time (ms)
Empty screen	11	33	0	0	0
Moving wallpaper	2	33	1	1	0
Single rectangle	0	50	0	0	0
Multiple rectangles	0	33 (-3)	0	0	0
Multiple RGB images	0	39 (+1)	0	0	0
Multiple ARGB images	10 (+3)	41 (-2)	2 (+2)	2 (+2)	0
Rotated ARGB images	57 (+3)	44	15	15	0
Multiple labels	7 (+2)	35 (+2)	0	0	0
Screen sized text	96	47	20	20	0
Multiple arcs	40 (+3)	33	7 (+1)	7 (+1)	0
Containers	4 (+1)	36 (-1)	0	0	0
Containers with overlay	88 (-1)	21	44	44	0
Containers with opa	16 (-1)	38	1 (+1)	1 (+1)	0
Containers with opa_layer	20 (+2)	34	5	5	0
Containers with scrolling	44 (-3)	45 (-2)	12	12	0
Widgets demo	71 (+4)	40	16	16	0
All scenes avg.	29 (+1)	37	7	7	0

ARM Emulated 64b - lv_conf_perf64b

Scene Name	Avg CPU (%)	Avg FPS	Avg Time (ms)	Render Time (ms)	Flush Time (ms)
All scenes avg.	25 (+1)	37	6	6	0

Detailed Results Per Scene

Scene Name	Avg CPU (%)	Avg FPS	Avg Time (ms)	Render Time (ms)	Flush Time (ms)
Empty screen	11	33	0	0	0
Moving wallpaper	1	33	0	0	0
Single rectangle	0	50 (+1)	0	0	0
Multiple rectangles	0	35 (-11)	0	0	0
Multiple RGB images	0	39	0	0	0
Multiple ARGB images	8 (+7)	41 (+3)	0	0	0
Rotated ARGB images	31 (+2)	33 (-1)	9	9	0
Multiple labels	2 (-1)	35 (+2)	0	0	0
Screen sized text	84 (+1)	46	18	18	0
Multiple arcs	33 (+5)	33	6 (-1)	6 (-1)	0
Containers	1	37	0	0	0
Containers with overlay	97	22 (-1)	41	41	0
Containers with opa	16 (-2)	38	1	1	0
Containers with opa_layer	7	35 (-2)	2 (+1)	2 (+1)	0
Containers with scrolling	46 (+1)	46	11	11	0
Widgets demo	67 (+2)	40 (-2)	15	15	0
All scenes avg.	25 (+1)	37	6	6	0

Disclaimer: These benchmarks were run in an emulated environment using QEMU with instruction counting mode.
The timing values represent relative performance metrics within this specific virtualized setup and should
not be interpreted as absolute real-world performance measurements. Values are deterministic and useful for
comparing different LVGL features and configurations, but may not correlate directly with performance on
physical hardware. The measurements are intended for comparative analysis only.

---

🤖 This comment was automatically generated by a bot.

[fabiobaltieri]

Pushed manually git push git@github.com:zephyrproject-rtos/lvgl.git 94ae6c053:master

[JarmouniA]

@fabiobaltieri Why was this merged so quickly!?

[fabiobaltieri]

@fabiobaltieri Why was this merged so quickly!?

Module fast forward, no need to wait, the opposite in fact, if someone merges it using the UI it's going to turn into a bit mess, we are trying to have automation push stuff like this automatically with no PR in the first place to avoid it in fact.

The manifest PR on the upstream repo is the one that goes through the process with the wait and everything.

[JarmouniA]

Module fast forward, no need to wait, the opposite in fact, if someone merges it using the UI it's going to turn into a bit mess, we are trying to have automation push stuff like this automatically with no PR in the first place to avoid it in fact.

Yeah, but as this is moving the branch from a stable release tag to master HEAD, I thought it would need to be tested on the Zephyr side to ensure the basic things are still working before merging it.

The manifest PR on the upstream repo is the one that goes through the process with the wait and everything.

We usually do not merge the accompanying module PR until it is tested & approved on Zephyr side.

[fabiobaltieri]

There's no point, this is tracking upstream we are not letting it diverge regardless, if there's changes on top of that they go in branches. Those would follow the normal process.

[JarmouniA]

There's no point, this is tracking upstream we are not letting it diverge regardless

The point of testing it before merging would be that if the update breaks many things on Zephyr side, we would stick with the existing release tag instead, and wait for future LVGL master commits that fix those breakages.

[fabiobaltieri]

Syncing the local repo to upstream does nothing on the Zephyr side. If updating the manifest breaks anything the fixes would go in a branch here.

[JarmouniA]

Syncing the local repo to upstream does nothing on the Zephyr side.

Sorry but it does, there is glue code on Zephyr side
https://github.com/zephyrproject-rtos/zephyr/tree/main/modules/lvgl

If updating the manifest breaks anything the fixes would go in a branch here.

I think we would like to avoid forking LVGL, unless I'm mistaken @faxe1008.

[JarmouniA]

Syncing the local repo to upstream does nothing on the Zephyr side.

Okey I kind of see your point now, we still can point the Zephyr manifest to any LVGL commit including reverting to the stable release tag in case there is an issue.

[fabiobaltieri]

Okey I kind of see your point now, we still can point the Zephyr manifest to any LVGL commit including reverting to the stable release tag in case there is an issue.

Yes, or pointing to a branch containing a fix if needed. The concern for how this repo is setup is merging commits on master that sends it out of sync, which the gh github does and we unfortunately can't disable, so there's value in not leaving these open for someone to merge them in the incorrect way by mistake (it happened).

[JarmouniA]

The concern for how this repo is setup is merging commits on master that sends it out of sync, which the gh github does and we unfortunately can't disable, so there's value in not leaving these open for someone to merge them in the incorrect way by mistake (it happened).

I see, thank you for taking care of it.