tmedicci commented on PR #6657: URL: https://github.com/apache/incubator-nuttx/pull/6657#issuecomment-1210705699
Hi! Thank you for your ack, @xiaoxiang781216 ! I understand `stride` as similar as the `pitch` from Zephyr's. However, it may not be necessary because de LCD driver usually keeps track of its own `bpp` and is able to calculate the `stride`. That is the case for st7789 at least. The current implementation does some kind of "row by row" write that enables partial refresh without using the `stride` from the framebuffer: https://github.com/apache/incubator-nuttx/blob/b8b541fbf5c75f13387560bb0639a4a5b27ec881/drivers/lcd/st7789.c#L450-L466 `size` and `skip` are defined as follows: https://github.com/apache/incubator-nuttx/blob/b8b541fbf5c75f13387560bb0639a4a5b27ec881/drivers/lcd/st7789.c#L567-L576 That is possible because of the `st7789_select(dev->spi, ST7789_BYTESPP * 8);` and the definition of the buffer as a `uint16_t`. I've tested a partial write for the ST7789 using framebuffer and everything works as expected (tested full row mode and an area that doesn't start at `col_start = 0` and that doesn't end at `col_end = xres - 1`) Also, it'd be possible to call `getplaneinfo` to retrieve the `stride` as well if needed by some driver. I may be missing something here, so I'd be glad to hear from you if that makes sense ;) -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
