v01d opened a new pull request #2208:
URL: https://github.com/apache/incubator-nuttx/pull/2208
## Summary
This PR adds an optional putarea() operation that can be supported by an
LCD. It allows to increase efficiency in transmission when the LCD supports
drawing more than one row at a time in a single transaction. The optionality is
done by not setting the callback pointer (drivers need not be changed since
when a member initializer for a struct is used, the non-initialized members are
default initialized, so the CB pointer is zero). On the LCD character driver
side, as discussed in #2166, if the LCD does not support putarea(), it defaults
to using putrun() for each row.
While this change is complete and tested, I think this opens up the door
other improvements that could be made to better expose LCD functionality. For
starters:
* putrun() is a particular case of putarea() so we could ideally remove it.
But since NX uses LCD api directly (I think this is a very limiting issue), NX
code should be changed to use putarea(). An alternative would be to deprecate
putrun() and do the change in the future, but now sure how that could work.
* LCD devices most of the time implement an internal "run buffer" which is
mostly needed because the LCD may not support doing partial transfers. For
example, some LCDs require a full row update. Other monochrome LCDs require to
send full byte transfers if some columns (bits) are altered. Furthermore, some
LCDs may not support more than one row per transfer. While in the latter case
an LCD would simply not implement putarea, if LCDs would support reporting the
minimum-maximum transfer size, an LCD would not require an internal buffer
(since the application would only perform transfers of the appropriate size).
Since most likely the application calling into the LCD will be managing its
drawing operations in its own buffer, an LCD consumes extra buffer space
unnecessarily.
* This is however not the case in NX when using LCD: NX assumes the LCD
solves this and does not use its own video buffer, it simply sends putruns() on
every draw operation (which is also quite inefficient since it does not
consider hidden objects, etc). So again such a change would require changes in
NX
* LCDs implement very specific functionality which sometimes is useful to
access. For example, I have an LCD which I can put into "fast mode" or not.
Other functionality could be enabling scrolling, screen inversion, etc. While
we could ideally add one callback for each of these (and one ioctl() to the
character driver) I think this does not scale well. I think we should support
the most basic common operations (maybe some of these are missing right now,
such as setting the backlight), it would be useful to add a `ioctl()` callback
to the LCD driver so that when an unimplemented ioctl is received by the
character driver, it is simply forwarded to the low level LCD driver.
From the above, I could work on the ioctl() handling. The other two
modifications require going into NX which I'm not personally interested in, but
maybe someone else does. Of course this would require discussion before
considering it. I personally think that (unless there's a good reason) NX
should be a userspace application such as X11.
## Impact
Add optional operation, does not affect existing drivers.
## Testing
With simulated LCD and LVGL
----------------------------------------------------------------
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
