v01d commented on a change in pull request #2208:
URL: https://github.com/apache/incubator-nuttx/pull/2208#discussion_r516829340



##########
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, 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).
   
   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?




----------------------------------------------------------------
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


Reply via email to