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
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
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
windo
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 opt
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 i
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 copie
