Adding drivers for EPDiy supported parallel epapers

[martinberlin]

The main contribution is to add a bridge driver to support EPDiy parallel epapers please check the table in that repository. My post in LVGL Forum where I got help and guidance to achieve this.

Please note that EPDiy requires a special PCB that is available in their repository. As an exception Lilygo has EPD47 that is an epaper available with it's touch component for about 49u$ in Aliexpress (Touch is L58 also in this pull request) Additionally I'm also adding support to other SPI epapers, like the big 12.48 inches from Waveshare, and others that are 3 or 7 colors with my component Cale-idf. But that's just an extra since SPI are too slow for me to use them for UX, I really like how it works with parallel epapers so far. Please tell me any part that I should correct. For example my library Cale-idf needs CPP but epdiy does not need it, so I could just change it to plain C.

UPDATE: I think it makes sense to add only EPDiy on this update so it's focused only on fast parallel epapers that can be used for UX. I will clean it up on the next days but hopefully it serves like it is to make further corrections.

[tore-espressif]

Hello @martinberlin , Thank you very much for your PR. According to your UPDATE, I changed it to draft, so feel free to change it back back when it is ready for review. I won't be able to have a look at it sooner then next week, so no rush.

[martinberlin]

Thanks @tore-espressif for your review. I cleaned it up days ago in my last commit and just resolved a merge conflict. Will make some more tests and I think it could be a candidate for review. My only concern is that in order to use this you need to add a new component (EPDiy) and of course that is optional to those that want to use parallel epapers but I don't know how it will play out with LVGL in terms of licensing and permissions to use external components.

Short proof-of-concept video of ESP32 with LVGL sliders, that on change value, are used to control ESP-MESH Lights

[tore-espressif]

Not a codereview, but just for clarification: Pfu, so this is a non-standard non-permissive license https://github.com/vroland/epdiy/tree/master/examples/weather#license I don't see any EPDiy files in this PR so I assume that

• everything you posted is you work and
• we won't be able to compile the code unless we add EPDiy manually to the project, correct?

LVGL is released under MIT license which allows commercial use, so these licenses are incompatible. I'm not a legal expert, so I'll try to get more info on this.

[martinberlin]

I don't see any EPDiy files in this PR so I assume that

Exactly like you assumed. Epdiy can be added as an external component. I collaborated with EPDiy library adding software rotation, and what I suggest is to use this forked EPDiy that has just the base library, and not any examples (Like weather) https://github.com/martinberlin/epdiy-rotation

The reason is to keep the size smaller and also because is the right way to add an ESP-IDF component directly with the files in the main directory. I guess the EPDiy main repository could be also used, but I really don't know what is the way to tell IDF that the component files are in subdirectories.

So yes I confirm everything I posted in this PR is my work. It needs an additional component that was programmed by @vroland and has another license. If the C files are added in CMakeLists this won't compile with the additional library. My proposal is to leave this files commented in CMakeLists so it's optional only for those that want to use it. EPDiy License is "GNU General Public License v3.0" so I guess without the examples it is compatible with MIT. I'm also not into this topics so you will have to check that first.

[lanistor]

Pelease merge this PR, we really need it.

[C47D]

@tore-espressif @kisvegabor Can we review the license situation on this PR?

[kisvegabor]

AFAIK, you can't use GPL in MIT projects because MIT would remove obligations stated in GPL.

[tore-espressif]

you can't use GPL in MIT projects because MIT would remove obligations stated in GPL.

Agreed, IIRC that's the reason we didn't merge it back in summer :(

[martinberlin]

Hello @kisvegabor and @tore-espressif

you can't use GPL in MIT projects because MIT would remove obligations stated in GPL.

Read in EPDiy project: Firmware and remaining examples are licensed under the terms of the GNU GPL version 3. Utilities are licensed under the terms of the MIT license. So right, then main component is using GPL v 3. Read a bit more about this issue here in stackexchange:

So if GPL-licensed code ever gets included in your project, for example via linking against a GPL'd library, you must also provide your whole project under the GPL. There's some disagreement on whether GPL comes into play when a library is dynamically linked; GNU are of the opinion that it does, and provides the alternative license LGPL, or recommends adding exceptions to GPL.

In my proposal, I'm not adding this copying the file, but is dynamically linked as a submodule: https://github.com/martinberlin/lv_port_esp32-epaper/tree/master/components

Question: Even if EPDiy project owner gives his permission, and this is dynamically linked as a submodule, is not possible that this 2 components coexist just because they use different Licenses? That is a bit troubling for me, because then it would limit the open-source effort considerably, and I will have to start checking Licenses first even before starting to collaborate in a project. Anyways thanks for the interest and for the support here, just wanted to clarify that this was done "as a best try" since never though someone would ever use it with epaper. So it surprised me in a good way that some people showed interest.

[embeddedt]

I am not a lawyer, so this is just my understanding of the situation.

The way EPDiy is included in the source tree is a separate topic from the question of dynamic linking and licensing. Having a GPL submodule is probably acceptable if there's a clear disclaimer on the repository. However, it's not very helpful to someone actually intending to use it in an MIT project, because whether the source is downloaded separately by GitHub or not, the final binary still includes GPL code, which means that all other code in the binary also has to be distributed under the terms of the GPL.

For this reason it's generally easiest to entirely avoid (L)GPL code in these types of situations. GPL contaminates the rest of the binary no matter what, and while LGPL has largely solved the problem for higher-level languages and ecosystems, it isn't much help for embedded where static linking is still the norm. LGPL requires the user to be able to replace the LGPL component of the code if they desire, which isn't practical in most embedded applications.

Still, I'd hate to see this effort go to waste. Does anyone know if it's possible to get CMake to conditionally download and extract a tarball at build time? That would avoid the issue of users inadvertently using a GPLed submodule without being aware of the ramifications. They would have to turn on the config option first and a warning could be printed advising them that GPL code is being included.

[C47D]

I'm not sure of CMake can do that. We can search tho.

My concern would be that the drivers repo is under cleanup and we might need to rework this.

[kisvegabor]

Even if EPDiy project owner gives his permission, and this is dynamically linked as a submodule, is not possible that this 2 components coexist just because they use different Licenses?

Dynamically linked means using a DLL on Windows or an SO file on Linux. This way the DLL or SO file not built "statically" into the binary, just placed next to it and "dynamically" loaded in runtime.

---

I'm not sure of CMake can do that. We can search tho.

The ExternalProject_Add could do that.

[martinberlin]

Many of the most common free-software licenses, especially the permissive licenses, such as the original MIT/X license, BSD licenses (in the three-clause and two-clause forms, though not the original four-clause form), MPL 2.0, and LGPL, are GPL-compatible.

I just noticed there is an Issue on epdiy where is suggested that if all contributors accept, the License could be moved to LGPL. If I see that clear, then we won't have this problem with GPL v3 vs MIT

[embeddedt]

LGPL improves the situation but still requires some sort of dynamic linking on the target platform, or the ability for a user of the product to rebuild the firmware with a different version of the LGPL component.

[martinberlin]

Only for your information: EPDiy has updated their license to Lesser GPL

[lanistor]

@embeddedt Will this be merged?

[embeddedt]

The question of linking/licensing still needs to be resolved. From my perspective, we can't include LGPL code in this repository without some sort of prominent disclaimer, since dynamic linking isn't common on embedded platforms.

[lanistor]

@embeddedt Thanks for reply, new try: https://github.com/vroland/epdiy/issues/174

[martinberlin]

I found some time to update this using the new epdiy V7 board which uses esp32-S3 and fast SPI external RAM (Octal at 80 Mhz) All source code and submodules are updated here: https://github.com/martinberlin/lvgl_epaper_drivers [Sample video test]

There are some issues to make this work faster:

1. LVGL has it's own display buffer which is not in PSRAM at the moment (we could add it but it will be silly)
2. epdiy has also one. Putting 1 in ext. RAM would be copying one to another in a slow SPI, well not slow at 80 Mhz, but you get the idea
3. Ideally this two should be the same but that requires a full rewrite of many parts of LVGL that I'm not sure if I would do
4. This display cannot receive parallel data at a bus_speed higher than 15 Mhz (ED097TC2 was tested by Valentin at 22 Mhz that is much faster) here using a cheaper version of the 9.7"

I asked also for a GT911 touch panel which is already supported in LVGL. Then we can try to optimize more. Lately I've got into producing epdiy v7 boards and sold part of them in Tindie. They are not cheap, since S3 alone with 16 MB PSRAM is about 4.50 USD plus other expensive components like TPS65185, to produce industry standard and soft regulated VCOM like the e-readers. Please note that all credits both for hardware PCB design, ideas and Firmware belongs to https://github.com/vroland who created this amazing parallel driver based on the new Espressif LCD module (Before used I2S parallel transmission mode) If you really would like to try it, note that Firmware is still being optimized and updated, you can get into the wait-list. I suppose end of September 2023 next 10 units will go to JLCPCB.