TimJTi commented on PR #17294: URL: https://github.com/apache/nuttx/pull/17294#issuecomment-3507417902
Is this is anything like SAMA5D2, the framebuffer is continually sent to the LCD (hdmi in your case) but the fb app (and lvgl before they modified it after feedback from me) write to it whenever so the written data garbles the screen image. With lvgl it caused tearing of a spinner, for example.Lvgl now uses 2 alternating render buffers which it copies to the framebuffer when ready. But I still think it is in no way synchronised with a vertical sync, and wastes time doing a 1.5mbyte memcpy every frame.The answer lies in the arch fb driver code, probably via FBIOCTL (from memory; sitting in an airport coffee lounge right now lol)Regards,Tim.On 9 Nov 2025, at 01:45, Matteo Golin ***@***.***> wrote:linguini1 left a comment (apache/nuttx#17294) I'm at a loss actually, I tried to copy the rendering method from rpi4-osdev bypassing the stuff in the fb example and the spots are still there. Not sure what's causing them. I don't think it's the overscan because if the over-scan pixels were in the framebuffer, the size would be much larger. I think the framebuffer has extra length due to memory alignment in the allocation process. If I shift the stride, or reduce/increase the resolution by 1, I get warped results as I would expect. The framebuffer example is all rendering fine besides the lines, which makes me wonder if it's something to do with timings between frame-buffer changes and HDMI video output/sync? Needs more experimenting. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***> -- 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]
