xiaoxiang781216 commented on a change in pull request #2208:
URL: https://github.com/apache/incubator-nuttx/pull/2208#discussion_r516853464
##########
File path: drivers/lcd/lcd_dev.c
##########
@@ -123,20 +123,56 @@ static int lcddev_ioctl(FAR struct file *filep, int cmd,
unsigned long arg)
{
case LCDDEVIO_GETRUN:
{
- FAR struct lcddev_run_s *lcd_putrun =
+ FAR struct lcddev_run_s *lcd_run =
(FAR struct lcddev_run_s *)arg;
- ret = priv->planeinfo.getrun(lcd_putrun->row, lcd_putrun->col,
- lcd_putrun->data, lcd_putrun->npixels);
+ ret = priv->planeinfo.getrun(lcd_run->row, lcd_run->col,
+ lcd_run->data, lcd_run->npixels);
}
break;
case LCDDEVIO_PUTRUN:
{
- const FAR struct lcddev_run_s *lcd_putrun =
+ const FAR struct lcddev_run_s *lcd_run =
(const FAR struct lcddev_run_s *)arg;
- ret = priv->planeinfo.putrun(lcd_putrun->row, lcd_putrun->col,
- lcd_putrun->data, lcd_putrun->npixels);
+ ret = priv->planeinfo.putrun(lcd_run->row, lcd_run->col,
+ lcd_run->data, lcd_run->npixels);
+ }
+ break;
+ case LCDDEVIO_PUTAREA:
+ {
+ const FAR struct lcddev_area_s *lcd_area =
+ (const FAR struct lcddev_area_s *)arg;
+
+ if (priv->planeinfo.putarea)
+ {
+ ret = priv->planeinfo.putarea(lcd_area->row_start,
Review comment:
> I understand, but all of these are reasons to have a buffer instead of
directly using LCD operations every time something needs to be drawn, not
reasons for the LCD framebuffer itself. Of course this driver offers a buffer,
but any application can simply create a buffer,
If the framebuffer is required in some case, why not directly use
lcd_framebuffer.c directly? For example, now LVGL support framebuffer
interface(/dev/fbx), and most likely will support LCD interface(/dev/lcdx). Do
you plan to support the third combination(userspace framebuffer + /dev/lcdx)?
or reuse the lcd_framebuffer.c + /dev/fbx? The later design is much better, do
you think so?
> draw there and then simply use the LCD driver with one putarea() for
any/all affected portions of the buffer (in fact, this choice is not available
in the LCD framebuffer, it always transfers the whole image).
>
No LCD framebuffer provide the interface to let GUI library control which
portion of framebuffer need update:
https://github.com/apache/incubator-nuttx/blob/master/drivers/lcd/lcd_framebuffer.c#L176
> The only reason for this LCD framebuffer driver would be for an
application written for a mmap'ed framebuffer interface which you don't want to
modify. But do we have such concern?
I really care about is how fast LVGL with the advanced UI(alpha blending and
smooth animation) can run on LCD panel. In this caseļ¼ the framebuffer plus lcd
is more suitable than pure lcd interface. lcd_framebuffer.c can work
immediately with LVGL porting.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
