@kdschlosser With this change the C tests are passing but the MicroPython test fails. How can we check the reason of the failure?

What is the problem with settings the color format after using lv_display_set_draw_buffers? Note that the color format is stored in the display anyway and buffers are always reshaped before rendering. So it doesn't really matter how the users set up the draw buffers initially because only the actual buffer (data) and its size (data_size) are used.

buffers are always reshaped before rendering

True. You are correct, there's no need to call lv_draw_buf_reshape here.

This is the error. You just have to go and look at the CI for the micropython test and it will tell you why it is failing.

Traceback (most recent call last):
  File "lib/lv_bindings/lvgl/tests/micropy_test/__init__.py", line 298, in test_1_image_compare
ValueError: not enough image data

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "lib/lv_bindings/lvgl/tests/micropy_test/__init__.py", line 318, in test_1_image_compare
AssertionError: Traceback (most recent call last):
  File "lib/lv_bindings/lvgl/tests/micropy_test/__init__.py", line 298, in test_1_image_compare
  File "/home/runner/.local/lib/python3.8/site-packages/PIL/Image.py", line 815, in frombytes
    raise ValueError(msg)
ValueError: not enough image data

It is telling us there is not enough image data. Meaning the color depth is somehow not right. The test script is collecting raw RGB data from the frame buffer so whatever change has been made is causing the wrong amount of data to be collected or the data that is being collected is not 3 byte RGB pixel data.

IDK where the artifacts are stored but in there should be a file with the raw pixel data that was collected so we can see what is going on.

It looks like you are trying to allow dynamic changing of the color format after the display driver has been initialized. Wouldn't the easiest way to be only to allow the color format to be set once and if the user wants to change the color format they would need to create a new display in LVGL in order to do that?

I say that because of buffer sizing. the frame buffers that have been passed in would need to be resized in order for this to work. In the case of someone that has passed in a raw buffer LVGL is not going to be able to handle that resizing and it would need to be done externally.

It could be explained but then how would the user go about changing the size of the buffer that is stored in LVGL? It would be easier to restrict a display's color format to only being set a single time.

Let me explain further on that.

When a display gets created in LVGL the user must tell the display what the frame buffers are. So lets use an RGB display as an example because it is easier to follow what I am saying.

Lets say the display is 480 x 320 and the color format for the display is RGB888. but for whatever reason the display when it was initialized is set to RGB565. That would mean the buffers are going to have a size of 480 x 320 x 2. Now if we allow dynamic changing of the color format and the user changes it to RGB888 guess what? You now have a buffer overrun condition because the size needed is going to be 480 x 320 x 3. If we flop flop it the other way around and the starting color format is RGB888 and we are changing it to RGB565 no you have a wasted memory use scenario.

You also need to remember these are MCU's we are dealing with so creating a second set of buffers or even resizing the frame buffers might not even be possible due to memory constraints. having to add 153600 bytes to an already existing frame buffer while everything is up and running is going to be a hard thing to do because the entire frame buffer would need to occupy 460800 bytes of contiguous memory. Due to memory constraints the frame buffers are one of the things that get allocated first in order to secure that amount of contiguous memory because there might not be that must contiguous space available later on. This problem gets even more compounded when dealing with double buffering.

Artifacts are not created automatically, but require explicit steps in the CI. Like this.

I think it was crashing because the buffers were NULL in set_color_format as you set the buffers only after that. See here. I added a fix, let's see if it passes now.

In case of screen sized buffer, the user really might need to set new buffers, which is doable and a reasonable expectation from the user. It's better to keep this opportunity open than limiting to setting the color depth once.

And passed! Could you improve the log to indicate if there was a crash and where was it?

I will need to have the problem duplicated and debugging turned on in order to see why the error didn't surface like it should have.

We need some feedback on this pull request.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.