LV_COLOR_DEPTH 1 results in segmentation fault

Hello All,

I am brand new to lvgl and got the simulator running with SDL2.
I am trying to simulate a small screen 240x400 with a color depth of 8 bits.
So I edited the lv_sim_vscode_sdl/ui/simulator/inc/lv_conf.h to this:

#define LV_COLOR_DEPTH 1

However that results in a segmentation fault.

rm -f ./build/bin/demo && make clean && make -j8 && ./build/bin/demo
[Warn]	(0.000, +0)	 lv_init: Memory integrity checks are enabled via LV_USE_ASSERT_MEM_INTEGRITY which makes LVGL much slower 	(in lv_obj.c line #138)
[Warn]	(0.000, +0)	 lv_init: Object sanity checks are enabled via LV_USE_ASSERT_OBJ which makes LVGL much slower 	(in lv_obj.c line #142)
Segmentation fault (core dumped)

The code is otherwise the same as the git repo:

Any help is appreciated.


Did you manage to find a fix for this? I’m on simulator 8.0.0 for VS Code and running into the same problem.

I think, when having a color depth of 8 bits per pixel, the correct setting would be
#define LV_COLOR_DEPTH 8

I agree, the OP may have made a mistake. But setting color depth to 1 (which is my intention with the simulator for prototyping a monochrome display GUI) still causes a segfault, specifically here:

Hmm, seems to be writing into a wrong memory location.
A mismatch of buffer sizes? As far as I can see, a color depth of 1 also needs one byte per pixel on lvgl side

Is there something else that needs modification for the LVGL simulator to run properly with 1-bit color depth? The same problem occurs when I try to set color depth to 8. I’m running the simulator on Ubuntu 22.04. The only changes I have made to the original repo are:

  1. Changed LV_COLOR_DEPTH to 1 in lv_conf.h
  2. Changed LV_BUILD_EXAMPLES to 0 in lv_conf.h
  3. Commented out lv_demo_widgets() from main.c
  4. Added a “Hello world” label in main.c to be displayed

This was indeed a buffer problem. The hal init function in main doesn’t account for color depth selection when setting the draw buffer, so any color depth value besides 32 results in a segfault. I can open a PR with a proposed fix, but I don’t know if this was intentionally left as-is and would prefer to not embarrass myself on GitHub if that’s the case.