TimJTi commented on PR #12733: URL: https://github.com/apache/nuttx/pull/12733#issuecomment-2238782332
> Thank you @patacongo !!! @XuNeo since you are working on LVGL V9 could you please take a look and help Tim on that? Thank you for your comments. Having slept on it I have realised my solution is right...but in completely the wrong place. It belongs in LVCGL not NuttX which is what I had thought until convincing myself otherwise. I *am* right that LVGL was "messing" with the framebuffer and homed in on a SAMA5D2 driver issue; but the LVGL NuttX framebuffer is rendering DIRECT to the framebuffer, not to it's own draw buffer. This is contrary to the basic principles of LVGL - set up a buffer or buffers for LVGL to render to; flush it to the display; notify that the flush is complete; repeat. I will reopen my issue on LVGL as this needs to be addressed there. I will keep this PR open for a short while as it is a useful place for a discussion and NuttX issues get more attention than LVGL ones do, sadly. But I like the idea of NX and RAM backed windows but I am not sure what "a LGVL compatible framebuffer driver for the NX windows" would be like? Since LVGL simply renders to a buffer that is setup in user-land, can an app not simply use LVGL to render to an NX RAM-backed window without any change to the NX/NuttX ecosystem? Very interested to discuss this further - when I asked a question that was 100% related to this issus @gregory-nutt essentially said the same: LVGL on multiple NX windows would be super cool; and my nascent App could easily use multiple NX windows, many of which have independent LVGL graphics rendered to them. Bring it on!! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
