xiaoxiang781216 commented on code in PR #6551: URL: https://github.com/apache/incubator-nuttx/pull/6551#discussion_r912355692
########## drivers/lcd/Kconfig: ########## @@ -18,6 +18,15 @@ menuconfig LCD if LCD +config FB_REDRAW Review Comment: > So if there is Null argument whole content of frame buffer is send to driver and next driver redraws the screen. I would like to stress that there are three steps to display something: > > 1. User app writes into the frame buffer > 2. Content of frame buffer is moved into the memory of driver > 3. Display generates picture on base of memory data. It is done "automatically". E-ink is an exception of a rule. There is a special command that generate the picture. Why not merge step 2 and 3 into one? I am not familiar with E-ink. Does E-ink have special requirement? > > > You can pass NULL pointer to indicate to update the whole screen > > > On the other hand in order to synchronize frame buffer with driver we have to call it. After your suggestion I'm going to: > > > > > > * modify function that synchronize fb with driver (this function is called after ioctl(.., FB_UPDATE, ..). After modification e-ink will redraw its content > > > * leave Kconfig changes > > In my previous implementation FBIO_UPDATE was triggering the step 2 and FBIO_REDRAW was triggering the step 3. I'm going to implement that FBIO_UPDATE with null argument triggers the steps 2 and 3. When we copy whole frame buffer, there is no need to specify area. You can still merge step 2 and 3 even FBIO_UPDATE with area, I think. area just mean update the full screen to simplify the most common case. > > > It's no real difference to ioctl(FBIO_UPDATE) or ioctl(FBIO_REDRAW). > > > I'm trying to solve bug that I discovered in SSD1680 driver. > > > > > > If so, the ioctl is better to define for SSD1680 only. > > There is no need. SSD works corectly when we copy all rows. The problem was when I was updating some rows. I noticed, that the content of not modified rows was changed. ioctl(.., FBIO_UPDATE, NULL) will solve the problem. > > > The problem exists if we are updating some pixels in drivers memory, but when we update all pixels everything works perfectly (hardware bug???). So I'm going to postpone updating the memory of driver till we want to redraw the screen. Before redrawing the screen all the content of shadow of frame buffer will be sent to e-ink display. > > > > > > this is exactly reason why FBIO_UPDATE was created. > > I think, that it was created to avoid of using task that periodically updates the driver memory (read data from frame buffer) or a task that compares the content of drivers memory and frame buffer. Display's memory is updated when frame buffer has different content then display. I'm going to extend functionality of FBIO_UPDATE by triggering step 3. Only e-ink drivers need this trigger. FBIO_UPDATE work with the hardware which isn't transfer the framebuffer continuously to the panel, but require the manual trigger: 1. Software update the frame buffer content as need 2. Manually call FBIO_UPDATE to trigger the transfer when the update finish > > > There is one more reason of using shadow buffer (it consumes memory): implementation of function that read the content of display. The SPI driver have no implementation of half duplex mode and the display wokrs in SPI half duplex (MISO and MOSI lines are shared). > > > So concluding there are many reasons of using FB_UPDATE. The drawback of FB_UPDATE is that some application may call to often FB_UPDATE functionality. On the other hand such applications should be modified to work with e-ink display -- 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. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
