Garbage output when using LV_DISPLAY_RENDER_MODE_PARTIAL/DIRECT

How-to
1

What do you want to achieve?

I want to check the capability of LVGL on my new platform. Initially, I am testing all three render modes:
(1) LV_DISPLAY_RENDER_MODE_FULL
(2) LV_DISPLAY_RENDER_MODE_PARTIAL
(3) LV_DISPLAY_RENDER_MODE_DIRECT

The problem is that only LV_DISPLAY_RENDER_MODE_FULL is working fine. By “working fine,” I mean that no garbage is displayed and the image is crystal clear. However, for the other two modes, only the first call works correctly. From the second call onward, garbage is displayed.

So my question is:
**

Do I need different flush callbacks for different modes? Currently, I am using a single flush callback.

**

What have you tried so far?

I have tried all three render modes.

Code to reproduce

void flush_cb(lv_disp_t * disp, const lv_area_t * area, uint8_t * px_map)
{
uint32_t *Color = (uint32_t *)px_map;

// Perform a dummy read to get valid data
// Read the first pixel and discard it.
volatile uint32_t dummy_read = *Color;

// The pointer is now pointing to the second pixel's data.

for(uint16_t Row = area->y1; Row <= area->y2; Row++)
{
    for(uint16_t Col = area->x1; Col <= area->x2; Col++)
    {
        PixelSet(Col, Row, *Color);
        Color++;
    }
}

lv_disp_flush_ready(disp);

}
Environment: MCU/MPU/Board: RH850
LVGL version: 9.3.0

2

Sorry boy, your old design work ??? Seems you knowledge about LVGL and displays is zero.

// Perform a dummy read to get valid data
// Read the first pixel and discard it.
volatile uint32_t dummy_read = *Color;

// The pointer is now pointing to the second pixel's data.

absurd code…
And all your issue is use PixelSet without info how it do.

3

Thanks for your feedback.

I’d appreciate it if we keep the discussion focused on the technical issue rather than personal remarks.

Regarding the dummy read: it was added intentionally to handle a suspected hardware/interface behavior where the first read returns invalid data (a pattern sometimes seen with certain display buses or memory-mapped peripherals). If this assumption is incorrect for this controller, I’m open to correction—please share details of the expected read/write behavior so we can align.

As for using PixelSet, I agree that understanding its internal implementation is important. My current goal is to validate LVGL’s render modes (FULL, PARTIAL, DIRECT) on this platform and identify why PARTIAL/DIRECT produce corrupted output, while FULL works as expected.

If you have insights specifically on:

  • Correct buffer handling for PARTIAL/DIRECT modes
  • Flush callback expectations
  • Any controller-specific constraints

that would be very helpful.

Let’s focus on resolving the issue together.

4

I can only explain why FULL work. For normal driver code after init displays is full screen memory set to “write update area”. Then any repeat write full screen will produce OK result. Specialy if PixelSet only write data for pixel without setup position. Hope you now understand why only this work.

1 Like