Added support for LittlevGL library #6826
Conversation
vanwinkeljan
requested review from
anangl,
dbkinder,
jukkar,
mbolivar,
nashif,
superna9999 and
tbursztyka
as code owners
|
@vanwinkeljan can you rebase this against the latest master? There's a bunch of commits that don't belong to the PR |
|
@carlescufi What is the normal approach if you have dependencies to other PR? |
|
While I can imagine this being useful, this adds a lot of code (over 180k lines) that has to be tracked and updated each Zephyr release. |
this will hopefully be one of those dependencies that will have to be maintained externally to zephyr, i.e. in its own repo in the project or similar to openthread. |
those are not-merged patches from the SPI PR.. |
@vanwinkeljan @nashif sorry, I didn't realize. Sorry for the noise. |
|
Thanks for pushing this. It would be great to get some gui support for zephyr. I am also hoping that someone would create a driver for the small oled displays that are used a lot in this field.
I did not quite understand your comment about makefiles. Could you elaborate a bit more why we would not do similar things as what subsys/net/lib/openthread is doing? Adding a version requirement for cmake should be avoided IMHO. |
|
@jukkar Problem is that lvgl repo has no top level makefile so if we would like to use the ExternallModule cmake module instead of a FetchContent module a top level makefile needs to be added after fetching the lvgl repo, in case of the FetchContent module ext/lib/gui/lvgl/CMakeLists.txt can be used to build the lvgl library. Further note that there is already a requirement for a minimal cmake version (3.8.2) and I just bumped it to 3.11. |
vanwinkeljan
requested review from
jhedberg,
SebastianBoe,
sjanc and
Vudentz
as code owners
|
@nashif @pfalcon @embeddedt In the end I pushed the CMake |
how exactly adding "gazillion" files to the source conflicts with the the project being a scalable RTOS? if you do not want this feature, it will not go into your resource constrained device. Note that some hals go into 100s of MBs and we still have them in the tree.
the same way we update any other external components.
We do not support git sub-modules. West is not ready, this PR has been open for almost a year now waiting for west or something similar, it is time to move on and use west when west is supported and ready for this. |
ok, thanks. I have no problem with that. |
Thanks, that's great step, makes things much more clear/manageable! |
Does that mean that we should add more stuff to the tree indiscriminately? I maintain JerryScript and MicroPython ports for Zephyr, should I push them into the tree?
Well, we're already regularly late with their updates, delivering stale/buggy content the users. Not just we do that alone, we actually promote that way, by effectively making forks of projects for nothing else but them becoming stale in our tree.
Poor us.
Well, I've overlooked that it's from March last year. And I'm definitely all for gratifying contributors with merging their patches sooner rather than later (applies to my patches too). I'm just not sure that the compromise between the choices - "slurp yet another large 3rd-party project as a codedrop into the tree" vs "give in to the logic and use git submodules" - was the right one. I'm glad that a solution was found. Regarding west, we can learn our lessons as we go. If we'd have chosen git submodules (or another existing tool), there wouldn't be such problems. And if we made west a frontend on top of git submodules, we could use submodules "in raw" while waiting for west to complete. |
|
@nashif: I also wanted to tell that for a long time, just couldn't think of a good way do that. So let me just do it straight: github does not notify in any way an author of a review when their review is dismissed. Consequently, if you want to give an author of such a review an opportunity to check that the issues were actually fixed, they need to be somehow notified - maybe by including @mention in the dismissal description, but I'm not sure if that works (need to test), and otherwise by a straight comment with mention. And conversely, if the aim is to sneak some code past the normal review process and leave the impression that all PRs are approved unanimously, make sure to not mention the dismissal to affected persons, and they'll never know ;-). |
As a heads-up: we're planning to release the next version of LittlevGL (5.3) this month. The release after that is planned for June. |
|
@embeddedt: Thanks for heads-up. Generally, my idea is that people should be motivated to work directly with upstream projects (bug fixes, etc.). And including an upstream project by reference motivates doing that, whereas including it by copy arguably demotivates that, driving towards "compromises" like "oh, we need to cut the release soon, let's just push that fix to our copy, we'll deal with all that later". And later only becomes more and more later. And as pointed by @nashif, we already doing/have to do that with vendor HALs. Well, that should be the motivation to NOT do that with community-maintained open source projects. |
Extend display API screen info with double buffer enum entry. Signed-off-by: Jan Van Winkel <[email protected]>
Added glue logic to interface Zephyr with LittlevGL GUI library This includes: * KConfig options for all lvgl options * Kernel & user space memory management * Zephyr to lvgl FS call mapping * Color space conversion function Signed-off-by: Jan Van Winkel <[email protected]>
Added a basic sample showing how to use the LittlevGL library in an application. Signed-off-by: Jan Van Winkel <[email protected]>
|
@nashif Updated the sample.yaml file, I did remove native POSIX target as it depends on SDL2. I don't think it is included in the CI docker container and as suche the build will fail.
Another question should I add myself to CODEWONERS for lib/gui ? |
yes please |
|
Hi, @vanwinkeljan notified us at about you have integrated LittlevGL. As the author of LittlevGL I was very happy to hear that! My question is if you would be interested in writing a blog post on LittlevGL's blog about getting started with Zephyr and LittlevGL. I found this description but I meant a something that is for beginners with Zephyr. It could a good option to introduce and promote Zephyr. So would you be interested? |
West is in full swing now. Is there already a github issue filed or work in progress to move LittleVGL to west? If not I can file one. I'd like it not to be low priority because right now this component seems to be the only one that breaks using sanitycheck offline. |
|
Thx @vanwinkeljan . I realized the problem is not whether the lvgl module has its own git repo or not. From what I've seen so far, moving modules out of the main repo is a Good Thing But it never makes any module magically more modular or optional. Sorry for this west digression.
|
|
@marc-hb |
This "lvgl" above sounded like |
|
@marc-hb yes with |
Added support for LittlevGL GUI library.
From LittlevGL website