Integrate bindings to lv_drivers into lvgl-sys

[nia-e]

Currently not mergeable as core functionality is missing, but opening to be able to track progress and discuss relevant points.

I decided to integrate drivers into lvgl-sys behind a feature gate as splitting them into their own crate(s) appeared to just result in a lot of pointless code duplication. Current absolutely-must-do TODOs before I mark this as ready:

• Make sure lv_drv_conf.h only gets compiled in and reexported if the drivers feature is enabled Done!
• Actually reexport driver functions and values Done!
• Figure out libraries that must be included to get certain drivers building (e.g. evdev, libinput, drm) Done!
• Merge Bump LVGL version to 8.3.5 #67 and rebase Done!
• Merge Rust bindings API review #51 and work functionality into the new API Done!
• Basic unit tests Done!

Other things I am more willing to procrastinate on but still need to be done:

• Create examples Done!
• Write documentation on how to use these features
• Update the main README.md with progress on input devices Done!
• Test cross-compilation and real-world use

Closes:

• LVGL-rs on Raspberry Pi #33

[nia-e]

What's the situation with regard to display support? I updated the README to state that both lv_drivers and embedded-graphics can be used for driving the actual panel/window. Is this desirable behavior? I have not looked into the code integrating with the panel itself, but if it strictly depends on having a struct implementing DrawTarget then I assume I should add a method on UI such as disp_drv_register_raw() which simply takes in the lv_drivers functions as parameters and bypasses embedded-graphics completely?

[rafaelcaricio]

@nia-e I think the way forward would be to change the public API as in the PR #51

[nia-e]

Alrighty. In that case I'll shelve this temporarily while I get #51 sorted and come back to it after. Will keep this open as I suspect it shouldn't take that long.

[nia-e]

Going to get back to work on this now; my current idea after familiarizing myself with lv_drivers somewhat is to bypass the way we normally register display/input drivers since I don't see a good justification for creating safe abstractions for the lv_drivers functions. Also, making a function that just returns an initialized Display or InputDriver would be unnecessary overhead. I'm thinking of instead defining a macro (which expands to some unsafe C FFI code) for each supported driver so that we can do more complex arbitrary logic entirely inline - is there any reason I shouldn't do this?

[nia-e]

This is almost ready; all that's left is to write some unit tests and mess with the build script to link in libraries for certain features. I'll also write some docs before merging.

[nia-e]

I had to take a short break for personal reasons but this is done and verified working. I ported the button_click example to rely on SDL through lv_drivers instead of embedded-graphics and it works perfectly. So, I think this is good to go as-is

[rafaelcaricio]

@nia-e Thank you for all the work. I just noticed that I pressed "rebase & merge" and I got added as co-author of your commits. 🤦🏽 Next time I will just ask you to merge yourself. Sorry about that!

[nia-e]

Don't worry! Plus, I forgot to squash... oops, I have a lot of commits in the tree now