Upload ESP32 drivers to Espressif's component registry

[tore-espressif]

Upload this repository as to Espressif's component registry, in order to enable ESP users to create LVGL project with idf-component-manager.

More information about idf-component manager can be found in Espressif API guide or PyPi registry. The component service itself is hosted here.

• Add idf-component manifest
• Add Github action for automated upload upon release
• Add documentation to promote this new feature

[C47D]

Hi, I think we should agree on the branch naming scheme before adding this capability.

I suggest a legacy branch were all of what we currently have would go, because the rotation handling we have doesn't match LVGLs, I've seen some issues related to this.

Master should be the branch were we work towards the @tore-espressif suggested v1.0.0.

I don't personally know how to handle this, my free time has been reduced lately and I would love to spend it in here, there's so much to improve :), what do you think?

@kisvegabor @tore-espressif @embeddedt

[tore-espressif]

Start of versioning:

I suggest a legacy branch ...

I wanted to tag everything that we have now with tag v1.0.0 and release after all issues in
https://github.com/lvgl/lvgl_esp32_drivers/milestone/2 were solved. This way, we will have a fixed starting point, vital for future development.

That means v1.0.0 would support LVGL v7 and it would not be fixed/maintained anymore. Users that want to use LVGL v7 would use v1.0.0 and everyone else would go for (yet to be) refactored v2.0.0 and LVGL v8.

the rotation handling we have doesn't match LVGLs

So this feature would go to v2.0.0

Branching strategy

One picture is better then thousand words:

First release (v1.0 in the picture) happens from master branch, so everything that is supposed to be in v2.0.0 must go to develop branch (that might be rebased on v1.0.0 tag).

Branch naming

picture - our name
Master - master
Develop - develop
Hotfix - hotfix/hotfix_name
Feature - feature/feature_name
Release - release/semantic_version

[kisvegabor]

We haven't came to a decision regarding the monorepo idea. In the past few weeks I was seeing the issues through the glass of the monorepo concept, and I believe that it'd be a good direction, especially for the drivers.

I'll warm up that topic today and propose to go for the monorepo.

So I suggest waiting a few days with the decision of branching strategy here. If we can really move to the direction of monorepo the branching should follow the branching of lvgl.

Do you agree with this?

[tore-espressif]

So I suggest waiting a few days with the decision of branching strategy here. If we can really move to the direction of monorepo the branching should follow the branching of lvgl.

No problem with the delay, there is no rush.

I believe that it'd be a good direction, especially for the drivers.

In long term, yes. But we are pretty far from making drivers from this repository platform-agnostic. There were some unsuccessful trials in the past (#1), and now I see why it is so complicated.

Actually, just for your consideration, if you write an LCD controller driver with all its graphical interfaces (SPI, parallel, or other) and then strip down the driver from all platform-specific code, there is very little left.

Basically the LVGL flush callback can call platform-specific HAL to flush the graphical data via SPI/parallel port, so there is (almost) no need for platform agnostic layer. It has its place only in LCD controller configuration (e.g. initialization).

That's why we are considering providing more advanced drivers (where users can choose their graphical interface - not possible now), but only for ESP. Let's be practical: It'd be easier for other vendors to 'modify' the driver for their platform, than providing extremely complicated platform-agnostic layer.

The reasoning here is, that no fixed interface is better than interface so complicated, that it will discourage everyone from using it.

Let me know whether it makes sense. If I come up with something worth sharing about LVGL's monorepo, I'll post it here lvgl/lvgl#2456

[kisvegabor]

@tore-espressif
I agree that it's a complicated topic. Probably that's why we don't have a good solution for it yet. 🙂

As I mentioned in lvgl/lvgl#2456 (comment) I think moving the development of drivers to the lvgl repo would help to get more attention. We can use a different branch for design, planning and evaluation.

---

So it seems there are 2 things here:

1. How to maintain this repo
2. How to proceed with the new drivers architecture

For 1) (specific to this repo) we can use whatever branching, versioning, etc you find the best. As you and Carlos work the most on this repo, it should be something you find good.

For 2) (tightly related to lvgl repo) we should follow the "philosophy" of the lvgl repo (or change it if required).

Do you agree with this so far?

[tore-espressif]

the "philosophy" of the lvgl repo

I'm not sure whether I understand this correctly

[kisvegabor]

I meant if the new driver architecture were be part of the lvgl repo it needed to follow the branching, release, tagging, etc. of the lvgl repo. Which is quite obvious.