Commit Graph

11 Commits

Author SHA1 Message Date
Tiago Medicci Serrano
ab60d0d3fb Framebuffer's callback buffer starts from the area being drawn.
The commit 664d45dcba updated the
behavior of the framebuffer's putarea callback enabling it to be
used to draw a particular area of the display. Previously, putarea
was only used to draw the entire area of the display. Any different
area was drawn, row by row, by putrun. Also, before checking for
which callback to call, the framebuffer driver adjusted the buffer
reference that was going to be used for calling the driver's callback
to point to the init of the relevant data. After that commit, the
framebuffer's buffer reference passed to the driver's putarea now
contains the data to draw the entire display. Unlike the previous
version of that implementation, only the putrun's callback buffer
was being referenced from the address that contains the data that
actually is being drawn.

This commit fixes it by adjusting the reference for the run buffer
passed to the putrun/putarea callback. It always starts from the
beginning of the relevant data that is actually being drawn. That is
necessary because lcddev (which uses the same LCD display driver
callbacks) actually don't allocate a buffer containing the data to
draw the whole display, so the same putarea implementation of the
LCD drivers would'n be able to work for both lcddev and framebuffer.
Also it's necessary to pass the stride argument to the LCD drivers
in order to enable them to do partial writes by calculating the
buffer offset while sending row-by-row. The stride is equal the
width multiplied by the bytes per pixel (may add some padding)
for framebuffer and is equal to the lenght of the row being drawn
(multiplied by the same BPP) for lcddev.

Why this approach?
Other possible approaches would be:
1) modify lcddev driver to translate received buffer data to a
buffer similar to the framebuffer. That wouldn't be efficient
considering memory allocation.
2) Create a new callback function. While possible, it'd be confusing
to create a different callback to draw the whole screen and another
to draw only an area of the screen. Also, these callbacks would
differ themselves only from the way the buffer is filled.
3) Simply reverting 664d45dcba would
break the usage of the putarea callback to draw an area of the
display, which would also be inefficient.

This approach is based on the Zephyr's implementation of the ST7789
driver: the buffer starts from the beginiing of the region that would
be drawn. The display device driver's putarea implementation should
check if the operation refers to a full screen/full row and implement
(if possible) a single operation to send the data to be drawn more
efficiently.

Finally, this approach requires that the drivers which implement
the putarea callback and expects the entire framebuffer buffer
to be modified. They don't need to calculate where the data begins
as the new buffer represents the data from the address that is
actually being drawn. This includes adjusting the LCD drivers
GC9A01 and ST7789 and the driver for APA102-based LED matrix display.
2022-08-13 20:36:45 +08:00
Karel Kočí
3693d38763 drivers/lcd/st7789: update implementation of driver for ST7789
'putarea' function now has to select the appropriate values from the
whole frame buffer instead of the previous expectation of having just
specified rectangle passed to it.

This required extension of WRRAM handling function as we now are not
writing simply buffer but we want to skip some values and do that
multiple times. Having two implementation in this case is worst as this
function is actually called only twice in the whole code (thus making
dedicated function for every call if we would have two variants).
Calling `st7789_wrram` multiple times is not an option as command
ST7789_RAMWR resets the position and thus calling it multiple times just
overwrites the previous values.
2022-07-22 11:08:00 +08:00
Yuichi Nakamura
f3dbc7bc63 drivers/lcd: getplaneinfo fix for ST7789,ST7565 and skeleton driver 2022-06-26 22:24:36 +03:00
Michael Jung
9140693567 Add lcd_dev_s pointer to lcd_planeinfo_s
In order to support multiple LCD instances per board, add a pointer from
lcd_planeinfo_s to the lcd_dev_s which it belongs to.  Also enhance the
putrun, getrun, putarea and getarea methods to pass through the
lcd_dev_s pointer to the respective device driver.

Port all LCD device drivers to this lcd_planeinfo_s extension.

Enhance SSD1306 driver to support multiple LCDs.

Signed-off-by: Michael Jung <michael.jung@secore.ly>
2022-06-21 21:33:23 +08:00
Peter Bee
ea6955f77b lcd/st77xx: change 16 bit cmd send to 8 bit
Make sending commands independent of processor endianness. The data can
be handled by application side, such as LVGL has SWAP16 option.

Signed-off-by: Peter Bee <bijunda1@xiaomi.com>
2021-09-17 09:46:16 -03:00
Peter Bee
23746d171f Add putarea() method for st7789
add st7789_putarea()

Signed-off-by: Peter Bee <bijunda1@xiaomi.com>
2021-07-02 10:08:26 -05:00
Xiang Xiao
2e54df0f35 Don't include assert.h from public header file
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
2021-06-03 08:36:03 -07:00
Yuichi Nakamura
aa718dcbac lcd/st7789: X/Y offset and screen orientation support 2021-03-16 06:35:04 -03:00
Alan C. Assis
ffc43c2d31 lcd/st7789: Make X/Y Resolution configurable 2021-03-14 20:05:33 -07:00
Gustavo Henrique Nihei
55d66f60a3 drivers: Fix typos reported by codespell 2021-02-25 18:57:18 -08:00
Michal Lenc
b11bfefff5 drivers/lcd: Added support for ST7789 controller based on ST7735
Signed-off-by: Michal Lenc <lencmich@fel.cvut.cz>
2020-12-23 11:19:53 -03:00