Lv_drivers sd2 builds/use unificaion for different OS-es

In short: while SDL2 used to abstract OS-depended things for PC drivers, user still needs to apply some OS-dependent actions in his code. It would be convenient to minimize such efforts (reduce to SDL2 install info only).


Currently, lv_drivers works somehow. But it’s not enough convenient to create unified “emulator” code, build-able on different OS-es. For example, in PIO i’d like to just run “build with sdl2 backend” and don’t care about details.

Imagine, we have sdl2 lib/headers installed and available via PATH. What i would like:

  1. Have the same code in userspace for all platforms. Proper options should be detected automatically, inside of lv_drivers, transparently for user.
  2. Option to force target platform (cross-compile to webassembly, for example)
  3. Use “standard” guards names to check platform, instead of custom ones.
  4. IMO name “monitor.*” is not enough descriptive. May be sdl2_monitor.* or sdl2_display.*? The same for keyboards/mouse/… All this can be implemented via different kinds of backends. Prefix sdl_ could improve things.
  5. Term “emulator” is confusing. That’s just a drivers for desktop OS. “PC drivers to develop GUI without bare metal” - IMO more easy to understand what is it. I’d suggest to review used terms in all docs.

Other questions:

  • Why windows-related code has separate entry (./windrv.*)?
  • Why separate thread created, instead of lv_task use? IMO single-threaded app will note require those init kludges. Precision of lv_task is medium, but should be ok for drivers.

Probably i misunderstand something. Sorry in advance if some questions are naive. Final goal is to make use of sdl2 more simple.

I’ve left aside some points, to focus on primary goal.

  • In PIO i can detect OS via extra script (and add build vars), but i don’t like to use this feature without need (now it does not solve “how to keep userland code simple”).
  • In PIO, it’s possible to automate windows sdl2 install to local project folder. Postponed until more high level questions solved.

One more thing. Seems monitor.c incorporates indirectly functions of more high level. Because “display” should not process “keyboard” events

IMO there could be explicit “sdl glue” shared component, responsible for init & events broadcast (it will also create internal lv_task for event polling). Then, any “driver” (display/mouse/kbd) could call independently init/subscribe/unsubscribe/quit methods. That will make each driver more isolated => more easy to apply next OS-dependent things.

Disadvantage: less precise interval of events scan (due lv_task nature). But this should not become a problem on PC. - IMO it would be more simple to use software mode everywhere, instead of guarding different “hardware”. HW acceleration should not give any valuable benefits for development. seems all key issues solved