Thanks for raising this, I’m a regular contributor to micropython and personally quite keen to see LVGL being seen as a standard part of the mpy ecosystem.
I agree that the lack of consioidated ready-to-go drivers is holding this back.
I’d love to see LVGL work as the GUI “creation” side of things, writing into a common micropython layer like framebuf and then have a standard api for drivers to be written for that glue framebuf to the hardware. framebuf does also include some drawing tools like line, basic text etc which is not helpful here… arguably framebuf isn’t providing anything needed here other than a concept of a width x height x graphics format buffer that is intended to be drawn somewhere - but this can be seen as a standard interface between the graphics “creation” / drawing side of a library and the hardware / displaying side.
Having a clear separation between the two sides would make it easier to re-use other existing drivers I believe, as well as clearly articulate what’s needed for writing new drivers which don’t neccesarily need to all live in the one repo then.
CP’s DisplayIO is interesting in that it’s got some driver support already, but it’s also quite integrated into some of their other codebase by the look of things and includes a bunch of graphics creation stuff we don’t need with LVGL.
russhughes has a stack of really high quality graphics drivers which are absolutely worth looking at; his standard repo structure also include a lot of graphics creation as you say, like lines, widgets, fonts.
Arguably LVGL doesn’t really need to know about the display driver at all if it can just handle filling a framebuffer, other than needing apropriate api hooks to force refresh (partial / full) and query any dispaly information that may be required.
This is separate to the input side of course, touchscreen and other controls are certainly needing to be part of the overall api, but the pure-python implementations of them for lvgl aren’t neccesarily a problem in my mind.