>From the putrun/getrun prototype:
int (*putrun)(fb_coord_t row, fb_coord_t col,
FAR const uint8_t * buffer, size_t npixels);
#ifndef CONFIG_LCD_NOGETRUN
/* Driver specific getrun function */
int (*getrun)(fb_coord_t row, fb_coord_t col,
FAR uint8_t * buffer, size_t npixels);
#endif
Can we extend npixels longer than one line to represent the multiple row?
-----Original Message-----
From: Matias N. <mat...@imap.cc>
Sent: Tuesday, April 21, 2020 1:55 AM
To: dev@nuttx.apache.org
Subject: Re: sending multiple rows to LCD in one go
I understand your interest in supporting the NX graphics system. No
intention to have any effect on that. To be clear: absolutely no change to
NX is needed here, so there is no API dictation from LCD driver towards NX.
I think LCD devices, as any other hardware device, need a driver for NuttX,
so exposing them with a standard API exposing its common capabilities would
always make sense, beyond what the NX system only requires.
It would be also interesting to hear opinions from other users of LCD
devices in NuttX, for example using littlevgl (or any other graphics system)
as I've read about this topic various times in the past.
As a final note, to put things in perspective, whie this optimization may
sound unimportant, in low-power applications that mostly wakeup to update
the LCD, reducing this time considerably extends battery life.
Best,
Matias
On Mon, Apr 20, 2020, at 14:09, Gregory Nutt wrote:
>
> > Didn't quite understood what you mean by "crappy" driver interface.
> My object is to support the core NuttX graphics system. Not user
> kludges to get low level access to drivers. That is unimportant
> because it is not on the OS roadmap. It was a mistake to create those
> userspace drivers in the first place and I definitely do NOT want them
> to dictate any graphics APIs or architecture. I would prefer to remove
> them then let them do that.
>
