I think I am satisfied that what I am seeing is a basic fault with the
LVGL V9/NuttX framebuffer driver.
LVGL V8/NuttX had, as LVGL traditionally needs, 2 buffers (full frame,
or partial, as required) and switches between them.
LVGL V9/NuttX directly uses the "/dev/fb0" framebuffer as best as I can
tell.
I believe it needs a rework of the lvgl framebuffer driver - which is
probably down to LVGL rather than NuttX people to sort; but I may see if
I can create a custom driver using the LVGL guidelines for now.
On 14/06/2024 11:13, Tim Hardisty wrote:
Thank you Gregory. I will read all of this and, so far, have skim read
the first you linked to and now understand it a little better already
and it confirms that the SAMA5D2 does indeed have a frame buffer
interface, that I register in my board bringup (so longer ago I'd
forgotten LOL) - but it could be that I could "upgrade" this since the
LCDC peripheral probably supports more than 1 layer with. various
advance functionalities - but NuttX may not of course.
I would like to use LVGL rather than NX simply because of the good
quality and flexible widgets that quickly allow a nice UI to be built.
Since the framebuffer example app works AOK, with no obvious image
defects, I am sure it's fundamentally OK.
I also recall that my brief experimentation with LVGL V8 via NuttX,
using the example app, worked with no visible artifacts, so I am
leaning towards some setup or other incompatibility between LVGL V9
(which purports to have NuttX support and was only recently
incorporated into NuttX to supersede V8) and NuttX, or the SAMA5, or
similar.
I will investigate further today as there are a whole heap of LVGL
settings with no documentation that I can find - either at LVGL or at
NuttX - so it could be I just need to find the the correct, arcane,
incantations. And also try reverting to LVGL V8 to compare behaviours
if necessary.
On 14/06/2024 03:39, Gregory Nutt wrote:
On 6/13/2024 8:32 PM, Gregory Nutt wrote:
On 6/13/2024 11:56 AM, Gregory Nutt wrote:
Changing the existing driver interface would break the NX graphics.
NX graphics is mis-named. It is not a graphics system like LVGL,
but a windowing system like X. Whatever you do should not break
the windowing system and, in fact, really should optionally
integrate with the windowing system.
There is some graphics support in apps/ now (called NxGraphics),
but that was never really fully developed. LVGL has the better 2D
graphics. NxGraphics can provide a Z-axis as well if properly
integrated with LVGL. There are several examples of window
managers that run on top of NX graphics NxTerms, NxWM, a tiny port
of a TWM-like window manger called Twm4Nx. These must not be broken.
So you have a few options: (1) Provide dual graphics that are
completely separate so that the existing graphic framework is not
trashed. That would not be cool. Or (2) Integrate LVGL with NX
Windows, or (3) both. Then you could have multiple LVGL windows..
which is really pretty cool. There would possible be some
performance hit, however. The simplest LVGL integration would be
to use per Window framebuffers. The current framebuffer driver
supports the whole screen. That is not the way other graphic
systems work. Rather they provide a framebuffer per Window. That
naturally supports Windows and cleanly provides multi-threaded
access to the display.
Here are URLs to some relevant documentation. I may or may not have
ever been leveraged into nuttx/Documentation.
*
https://cwiki.apache.org/confluence/display/NUTTX/Framebuffer+Character+Driver
*
https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem
*
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474
*
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629473
A couple more references that most people are not aware of:
*
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629398
*
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629401
