Relationship of lv_micropython and lv_port_esp32?

What’s the relationship between these two? When drivers get into lv_port_esp32, does that mean they’ll come to the micropython side automatically (or at least easily)? For example ST7789 was recently added to lv_port_esp32.

A short up to date list of available drivers on ESP32 in the lv_micropython page would be great. I see a few examples mentioned like ILI9341 but it isn’t clear what else is available. And another suggestion (which I’m sure you’e heard before!): a pre-compiled LV_MP firmware set with a few common displays supported would see a huge uptick in use! Thanks.

Hi @doublerainbow!
There is no relationship between the two, as of today.
They are developed and maintained by different people with different goals.
One important difference is that lv_port_esp32 drives are meant to be used by C code, therefore they are configured on compile time.
lv_micropython drivers, on the other hand, are configured on runtime. So if you need to change the SPI pins or some display configuration you don’t need to rebuild the firmware, only provide different parameters to the driver when initializing it.
Having said that, it should be pretty simple to pick up a driver from lv_port_esp32 as-is and compile it into lv_micropython. You would have to configure it when building the firmware though, and rebuild the firmware every time you need to change it.

  • ESP32 port:
    • ILI9341 and ILI9488 through the driver.
    • rtouch, that’s a resistive touch driver with minimal external components that uses 2 ADC channels directly connected to the touch panel
  • STM32 port: STM32F7DISC
  • unix/windows port has SDL driver
  • unix port has Frame Buffer and evdev drivers

These drivers are added upon need by whoever needs them.
If you add some driver you are welcome to open a pull request.
All drivers are under lv_binding_micropython/driver, so browsing this directory usually gives a pretty good picture of what is supported.

Yes I’ve heard this suggestion before.
So far we didn’t offer a prebuilt firmware for each port.
In many cases users need their own modification on their lv_micropython fork. In some cases users need to use LVGL with micropython fork other than lv_micropython (for example, CircuitPython) so I’ve seen little value for putting the effort into providing firmware releases.
However, having CI workflows in place could make firmware releases easier to maintain, so we may consider this in the future after having proper CI in place for esp32.