Yeah - I’m at a loss trying to understand your perspective? I can’t think of any use case where anyone would want a solution different to my proposal? What are you guys working on?
In my situation - I’m equipping my landcruiser which is set up for off-road touring, with a range of accessories (external floodlights, temperature sensors, ODBCII sender, GPS, LTE, Lithium battery monitors, TPMS, cameras, etc etc) which are all controlled by ESP32’s using espnow, BLE, and local wifi. The control and outputs for these things are ESP32 touchscreens (on my dash, and inside my tent, and in the back cooking area at least), and also via phone.
I’ve just ordered “one each” of every different sized display+esp32 combo I could find on aliexpress, in addition to the 3x 2.4" ones I already have. Almost every one of them uses different screen driver ICs and different touch driver systems. It’s a total dogs-breakfast shitstorm of cheap Chinese suppliers using whatever cheap boards they can to make product. You know - “real life”. If you’ve been around for more than a few years, you already know that there’s no time in the future where you will be able to keep getting the same screens. Everything changes, and rapidly. Thus, in my mind, there’s no place in the world for hardcoded or “baked in” LCD drivers in any firmware at all - it just makes zero sense, and the same goes for applications written to run on MCU’s: nobody in their right mind wants to build something awesome, but have to release 1000 different builds of it for people to use, based on their MCU+screen+pin decisions. Sorting out the hardware should NEVER be the responsibility of either application authors, nor Micropython itself, nor LVGL either. Hence the need for sanity in the declaration of hardware, and the distribution of drivers that use it.
Hope that sheds light on stuff? I’ve written MCU drivers for loads of different hardware over the last decade or so (and, before that, PC/Windows/Linux as well - my first-ever was a DAT tape-backup driver in about 1988!)… but that said - I do live in my own bubble. I don’t know what others have tried (if anything) to sanitize this mess to-date: all I know is that right now, it’s an unsustainable wreck that needs fixing.
p.s. My setup so-far is awesome-enough that I’m tinkering with the idea of running a crowdsupply campaign on it. Having absolute control of everything without having to run wires (other than power) is totally brilliant for cars, and would be amazing for loads of other uses as well. I’m thinking of calling it “GuPy” (for General-purpose Micropython") and shipping whatever minimal-set of hardware boards would be needed to support the majority of user screen needs, and most sensible list of sensors - like EGT sender, general purpose temps (winch body/cables/etc), CAN-Bus info, BLE transceiver for TPMS/UHF/ODBC/Audio/etc, FET switches for lights etc, engine immobilizer, GPS, GSM SMS/Data, datalogging, customisable display screens with dimming, app, cameras, radar, switches, level sensors (e.g. water), load cells, solar control, power current + voltage sensors and loggers, smart-switches (light sensors for night time auto-illumination), , data chart display to shows changes over time, alarms, fingerprint, keyswitch, mini solar, vibration charger, rf spectrum reader, shock sensor, voice recognition, speakers, water detector for airbox, temp+humid for fridge, alarms, radar, motion, reedsw, 9-axis thingo, gyro, magnetometer, innertia, 4g, lora, lidar, proximity sensor (car height), geiger, and anything else folks might want…
