Clarify the location of Zephyr specific LVGL code

[fabiobaltieri]

Currently the bulk of the LVGL Zephyr support code lives in the lvgl mirror repository: https://github.com/zephyrproject-rtos/lvgl/tree/zephyr/zephyr, this has been moved form the main upstream repository as part of the 8.1 migration zephyrproject-rtos/lvgl#15.

My understanding is that was a a path towards upstreaming that code on the main LVGL repo, but that hasn't happened.

There's more development work ongoing on LVGL (@faxe1008 @danieldegrasse), and I think that having the code in the module is making thing unnecessarily harder by requiring the extra PR for synchronizing the code.

Should we move the code back to the main repository in bulk for the time being and reconsider upstreaming it on a later stage?

CC: @nashif @gmarull @carlescufi @jfischer-no @pdgendt @brgl

[jfischer-no]

Currently the bulk of the LVGL Zephyr support code lives in the lvgl mirror repository: https://github.com/zephyrproject-rtos/lvgl/tree/zephyr/zephyr, this has been moved form the main upstream repository as part of the 8.1 migration zephyrproject-rtos/lvgl#15.

My understanding is that was a a path towards upstreaming that code on the main LVGL repo, but that hasn't happened.

Maybe some parts, but not the interface to our APIs.

There's more development work ongoing on LVGL (@faxe1008 @danieldegrasse), and I think that having the code in the module is making thing unnecessarily harder by requiring the extra PR for synchronizing the code.

Should we move the code back to the main repository in bulk for the time being and reconsider upstreaming it on a later stage?

I think the customizing/interfacing part to our subsystems/driver APIs can be moved to ./modules (similar to e.g. .modules/littlefs)

[fabiobaltieri]

I think the customizing/interfacing part to our subsystems/driver APIs can be moved to ./modules (similar to e.g. .modules/littlefs)

Cool, so you are suggesting that we should move this stuff: https://github.com/zephyrproject-rtos/lvgl/tree/zephyr/zephyr back to https://github.com/zephyrproject-rtos/zephyr/tree/main/modules (lvgl dir) and just do https://docs.zephyrproject.org/latest/develop/modules.html#module-integration-files-in-module in the module, right? I'd like that too.

[jfischer-no]

I think the customizing/interfacing part to our subsystems/driver APIs can be moved to ./modules (similar to e.g. .modules/littlefs)

Cool, so you are suggesting that we should move this stuff: https://github.com/zephyrproject-rtos/lvgl/tree/zephyr/zephyr back to https://github.com/zephyrproject-rtos/zephyr/tree/main/modules (lvgl dir) and just do https://docs.zephyrproject.org/latest/develop/modules.html#module-integration-files-in-module in the module, right? I'd like that too.

Yes, and take a closer look at it. e.g why is there https://github.com/zephyrproject-rtos/lvgl/blob/zephyr/zephyr/lvgl_fs.c and what it does...

[fabiobaltieri]

@faxe1008 would you have cycles to move the files back into the main repository under modules/lvgl? Then the ones in m//pull/60867 would go there as well and any other effort won't require the double PR anymore.

[faxe1008]

@fabiobaltieri just to clarify, you are talking about moving the files situated here: https://github.com/zephyrproject-rtos/lvgl/tree/zephyr/zephyr to https://github.com/zephyrproject-rtos/zephyr/tree/main/modules?

Sure, can do that after my vacation (2 weeks).

[fabiobaltieri]

@fabiobaltieri just to clarify, you are talking about moving the files situated here: https://github.com/zephyrproject-rtos/lvgl/tree/zephyr/zephyr to https://github.com/zephyrproject-rtos/zephyr/tree/main/modules?

Sure, can do that after my vacation (2 weeks).

Yeah, cool, no pressure, have a nice break!

[gmarull]

I think it would be nice to upstream the code, so that one can theoretically pick any LVGL version regardless of Zephyr version (provided both are compatible). Having to upgrade complex LVGL applications just because I need to upgrade Zephyr is not great (I've been through this).

[jfischer-no]

I think it would be nice to upstream the code, so that one can theoretically pick any LVGL version regardless of Zephyr version (provided both are compatible). Having to upgrade complex LVGL applications just because I need to upgrade Zephyr is not great (I've been through this).

This is not LVGL project code, but customization of our APIs and subsystems, which means that once up-streamed it will probably always be broken with the current Zephyr tree. It will also increase upmerge and maintenance effort, like we have the situation with MCUboot.

[gmarull]

I think it would be nice to upstream the code, so that one can theoretically pick any LVGL version regardless of Zephyr version (provided both are compatible). Having to upgrade complex LVGL applications just because I need to upgrade Zephyr is not great (I've been through this).

This is not LVGL project code, but customization of our APIs and subsystems, which means that once up-streamed it will probably always be broken with the current Zephyr tree. It will also increase upmerge and maintenance effort, like we have the situation with MCUboot.

Well, this assumes Zephyr APIs are very unstable, which in part is true because we have quite a few toy-like APIs. But TBH, the LVGL glue code has not suffered major changes over time (because graphics support has not evolved either). LVGL can always claim support up to Zephyr vX.Y, and upgrade when the maintainer has enough time.

[gmarull]

I see there's some Zephyr related stuff upstream already https://github.com/lvgl/lvgl/blob/master/env_support/cmake/zephyr.cmake
https://github.com/lvgl/lvgl/blob/master/CMakeLists.txt#L11

Added by the initial LVGL Zephyr maintainer: lvgl/lvgl@ed5f91a

[fabiobaltieri]

Between input and #60840 there's probably going to be quite some work on LVGL Zephyr support, I'm thinking we may be better off getting that done and stabilized in the main repo and think again about upstreaming once that's stabilized.

[gmarull]

Between input and #60840 there's probably going to be quite some work on LVGL Zephyr support, I'm thinking we may be better off getting that done and stabilized in the main repo and think again about upstreaming once that's stabilized.

sounds reasonable

[fabiobaltieri]

Work is ongoing to move this back to the main repo, closing this one.