Use driver as submodule

[amirgon]

Today lv_binding_micropython contains driver code such as SDL_monitor.c and SDL_mouse.c.
However, similar code exists on lv_drivers repo as well, which seems to do the same thing (SDL initialization and registration, for example).

I wonder if it would be a good idea to have lv_drivers as a git submodule of lv_binding_micropython.

• Pros: Avoid duplicated driver code between lv_drivers and lv_binding_micropython/driver
• Cons: Today all the drivers on lv_drivers are packaged together in one repo. A Micropython user will only be interested in a few drivers from there, so there will be some redundant code from his point of view.

@kisvegabor What do you think?

[embeddedt]

@amirgon Lots of our existing projects use only one driver from lv_drivers so I don't think it is a problem.

Examples:

• https://github.com/littlevgl/linux_frame_buffer
• https://github.com/littlevgl/pc_simulator_sdl_visual_studio

[amirgon]

@amirgon Lots of our existing projects use only one driver from lv_drivers so I don't think it is a problem.

@embeddedt How does it work for eclipse users who compile all C files under subfolders? (as we discussed here)

[embeddedt]

@amirgon All of the drivers have an #if USE_<driver name> preprocessor clause guarding them. There is an lv_drv_conf.h file used to configure which drivers are enabled. This prevents any of their code from being included.

[kisvegabor]

The lv_driversrepo is not so complete. Mainly the PC drivers are tested and maintained. For example you have no interface to use the emdebbed drivers with DMA.

So I also suggest using individual drivers which can be shaped to your system. The drivers in lv_driver can be good starting though.

[amirgon]

@kisvegabor I thought for the long term it makes more sense to use a submodule for drivers, which can be shared among lvgl projects and applications. If each repo keeps its own drivers, it would become harder to maintain a driver. You would have to update it in multiple repos.

I'm currently testing with the unix drivers. Do you suggest copying the unix drivers to lv_micropython_bindings (actually this is what I did for now) instead of using them from lv_drivers?

I'm going to add ILI9431 for ESP32 based on your esp32_ili9431 repo. Doesn't it make sense to add it to lv_drivers instead of maintaining it on both esp32_ili9431 and lv_micropython_bindings repos?

If we decide to use drivers from lv_drivers submodule, there is another question: Where to put the Micropython glue for the driver? The Micropython glue for driver is a small Micropython module that allows the Micropython user to register the driver from his script. Here is the glue module for unix display and mouse, and here is how it is used on Micropython script.
Would it make sense to put this glue on lv_driver with some micropython macros to enable/disable it, or on lv_micropython_bindings? It is driver specific code, but in the context of Micropython.

[kisvegabor]

Where to put the Micropython glue for the driver?

Actually, that's why I suggested copying the driver. As these are drivers for displays and input devices and independent from the host MCU it's difficult to make so flexible to support all the good stuff of a toolchain, MCU (DMA) or language (C, C++, Python).

It's true that if we copy the drivers their maintenance would be harder. However, as the drivers are usually customized they need to maintained only in there own place. So IMO it would be a too big effort for a small gain.

[amirgon]

Actually, that's why I suggested copying the driver. As these are drivers for displays and input devices and independent from the host MCU it's difficult to make so flexible to support all the good stuff of a toolchain, MCU (DMA) or language (C, C++, Python).

@kisvegabor I'm using the exact same driver for unix in lv_micropython/unix. The "glue" doesn't change anything inside it, just provides a way to call it from Micropython.
I understand that different MCUs might implement the same driver in different ways, but in this case the same MCU uses the same driver with/without Micropython, and here I see the code duplication.

It's true that if we copy the drivers their maintenance would be harder. However, as the drivers are usually customized they need to maintained only in there own place. So IMO it would be a too big effort for a small gain.

Ok, so let's keep it that way for now.
I will not use lv_drivers, and copy the driver code into lv_binding_micropython/drv instead.