That would indeed work as well. I did not suggest it to avoid modifying semantics of an existing call.
On Mon, Apr 20, 2020, at 16:02, Xiang Xiao wrote: > 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. > > > >
