Marlin
Marlin copied to clipboard
MarlinFirmware
[WIP] Refactoring LVGL integration
The goal is to remove LVGL configuration stuff from UI code and make lvgl already configured for extui that want to use it. It doesn't add anything in Marlin Core. It also add SDL display (Linux Only), mainly for developpement
- [x] Add lvgl and lvgl drivers
- [x] Add sdl display (use lvgl drivers)
- [ ] Wrapper around TFT_io for SPI/FSMC TFT (it's done, but it need a bit clean)
And i would also initialise LVGL filesystem for SD Card and Flash storage and upload assets if found on sd card
My Idea for flash storage, was to split it in 3 'lvgl filesystem'.
one for Font one for Bitmap (with a lvgl image decoder for compressed image) one for the Ui data
PS : Last commit is Linux configuration and hello world ui for lvgl.
Requirements
Linux or tft screen
for linux, sdl libraries
apt-get install gcc-multilib g++-multilib libsdl2-dev
Benefits
Easier to add LVGL UI, and developpe UI faster with SDL LVGL also support lcd screen, but i haven't one, so i' will not add it.
Any thought are welcome.
Johan
Do you know about the MKS's UI ? It's already using LVGL internally and it's quite complete already.
I agree that developing on Linux is easier than on the printer itself, but in the end, you'll have to simulate so many stuff (touch position, printer's interaction, G-Code, etc...) that I doubt you'll gain time.
Yes i know, but it used an old lvgl with no font loading support.(7.2) It only suipport one resolution, and dosen't follow all Marlin definition. Lvgl initilialisaton has problem, rotate screen dosn't work well for me, and there's few 'strange' code in MKS UI. Display Buffer is used for other thing that lvgl display buffer, so you can't use doubble buffer. Goal is to move lgl out fro ui, and make it accessible for all extui. And lvgl will be already configurer, with right touch input, right screen , right fylesystemI, and will manage assets uploading. Next step would be to make MKS ui use this library, and probably move it to EXTui. In fact, For now, i cannot print with MKS UI( don't test this branch), but 2.0.7 don't ever compile for me without few change and when compilation is fine, it pause itself during print with no info, but i can print via USB.
And for linux display, mouse is used as touch input, and mousewheel as encoder. so you can test some part of ui. you can't test everything, but designing the windows, etc is easier. and it add no code in Marlin as it use external lvgl driver library.
Currently, MKS makes an hacky use of LVGL filesystem to implement the G-Code preview icon feature. You'll have hard time fixing this (I've done it here, but it was rejected since it was solving a deprecated issue). Also, there is some outgoing effort to use LVGL 7 here. I don't know how good it is however.
I already did the mks ui working on lvgl 7, a long time ago. I will resurrect the branch.
Hello, i don't stop working on it, but can't work on it every week. Feel free to close it if you want, i'll reopen it when development from my side will be finished.
This has been brought up to date, cleaned up, and tweaked to conform better to Marlin S&P. Please work up a test compilation that succeeds and we can add it as a new CI test for continued development.
Thanks, i'm a bit busy now as my work is in bankrupt, and i have to do a lot of things for that. Hope i've more time in one month.
@rhapsodyv What is your LVGL7 branch you are referring to ?
It's a stash. I updated it with the last marlin bugfix.
I need to update the style code, that changed from 6 to 7.
I might send a PR in the next days. I'm just waiting the 2.0.8 release.
This pic is of the lastest lvgl (as you see, just re apply the styles now)
I've reworked the color picker widget in LVGL7 (submitted to lvgl repository, but they merged it in v8), so please @ mention me when you post your PR so I can send you the new code. It's required for #21158. Thanks!
I've reworked the color picker widget in LVGL7 (submitted to lvgl repository, but they merged it in v8), so please @ mention me when you post your PR so I can send you the new code. It's required for #21158. Thanks!
Using standard LVGL, we can just enable/disable it right on marlin lv_conf.h .
That's one of the things to do, but the cpicker is:
- too slow to draw without rewriting the drawing code
- expecting the TFT to send "PRESSING" event continuously (so you can switch the mode from HUE => Saturation => Value by long pressing the center of the wheel). This does not work with MKS's TFT code since it never send PRESSING more than once.
- styles are messed up in the current code base, so it display a white colorwheel that's unusable unless it's fixed.
See here for (1), the change for V8 is merged already See here for (2) and (3)
I don't know if (3) is fixed in your code (it might be), but (1) and (2) is really required for a working color wheel.
Honestly, the v8's dev branch is very far from the v6/v7. They reworked almost everything. So, it'll be a hard work to do. If your code is using v7.10, it's ok for me as my patch will apply (it applied on v7.11).
Honestly, the v8's dev branch is very far from the v6/v7. They reworked almost everything. So, it'll be a hard work to do. If your code is using v7.10, it's ok for me as my patch will apply (it applied on v7.11).
Won't they apply your patch on v7??
They approved it, but after discussing with the original author, they decided they won't apply any more patch to v7 and instead switched to v8. v7 is now in support-mode, it won't receive any change, only bug fix as far as I understood. See first link in my previous comment for the history and the patch.
So, it's best just ignore v7 at all, and ask MKS to merge your PR on v6... and them, later, make it work with v8.... it seems v7 is a waste of time at this moment...
I don't know when v8 will be released, but I agree with you, unless you are very close to a completely working solution.
Check out the simulator work underway at https://github.com/p3p/Marlin/tree/pr_linux_cleanup and give it a run. It uses SDL and IMGUI and currently emulates both a U8GLIB-based DOGM LCD and the TFT version of MarlinUI.
It would be cool to have a CI test for this and the Simulator, but it needs to download and build SDL2 as part of the test. I've Googled around for examples of doing this with PlatformIO but haven't found one yet. I'll keep looking around, but if anyone finds something in the meantime, please let us know!
This is still interesting, though it might be more suitable as an addition to the MarlinSimUI project. I went ahead and rebased it in case anyone still wants to experiment with this.