On 6/13/2024 11:15 AM, Tim Hardisty wrote:
I am getting in a mental pickle regarding LVGL (V9) and NuttX, in
conjunction with the SAMA5D2 with it's built in LCD Controller
peripheral.
In the past - bare metal - I have simply set up two buffers so one can
be written to while the other is copied out to the actual display. But
now NuttX is "in the way" ;-)
The NuttX support for V9 LVGL allows you to set it up to use a NuttX
LCD device - but I am pretty sure that us expecting a NuttX device
driver such as /dev/lcd0. The default configuration for the SAMA5 - I
believe - is to create /dev/fb0. I have that device driver registered
and it works - e.g. using the framebuffer example without issue.
I can get LVGL to use /dev/fb0 but the display "tears" and I think
that is because LVGL writes to the same single buffer set up for the
SAMA5D2 LCDC, but I can't work out how to get it all to work with 2
buffers. Or it's for some other reason maybe, but I can't fathom what
it might be.
Should I, somehow, convert the framebuffer to a "simpler" driver that
lvgl can work with to create 2 buffers? How?
Or does it need some work at the SAMA5D2 end of things? What?
Or do I need a "custom" lvgl fb interface of some sorts instead? Any
examples?
Thoughts and suggestions would be much appreciated!
Thanks,
Tim
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.
