TimJTi opened a new pull request, #12733: URL: https://github.com/apache/nuttx/pull/12733
The SAMA5D2 LCDC driver has memory mapped framebuffers that LVGL (for example) can write to directly causing issues. LVGL - and presumably other applications - need a buffer that they can render to and only when done should that be copied to the "real" framebuffers of the LCDC. I have added a function `CONFIG_FB_UPDATE` that can be called via the relevant IOCTL that does the copy and it has fixed the issue I was seeing in relation to screen artefacts I noted as an issue in the nuttx-apps repo [here](https://github.com/apache/nuttx-apps/issues/2416). I am not 100% sure what the correct way to address this is, so for now I have added a new Kconfig entry to allow an "EXT" memory buffer to be declared, and that is what is reported as the `pinfo->fbmem` memory location but it doesn't really feel right - and it seems there are no other architectures that address this so it is perhaps unique to the SAMA5D2? There must be a better/neater/proper way to be doing this? ## Impact It allows LVGL V9 to behave as expected, on this processor. I have tried to ensure that the driver reverts to the previous methodology if the new Kconfig entry is not present. ## Testing Custom board with SAMA5D27-D1G and 800x480 LCDC. Manually deleted new Kconfig entry to check the driver reverts to as before and, similarly, deleted the newly enforced `CONFIG FB_UPDATE` entry to check. -- 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]
