I’m using LVGL with Zephyr, which prevents me from directly modifying the display driver or LVGL code without breaking modularity. Almost all monochrome reflective/transflective and e-paper displays interpret 0s as white and 1s as black — the inverse of LVGL’s logic. I found a workaround by setting dark theme active and creating macros for lv_color_white (LV_COLOR_BLACK) and lv_color_black (LV_COLOR_WHITE) but this introduces a layer of ambiguity in the code itself and with respect to LVGL sim prototyping. From what I can see, it doesn’t look like there is a direct option to “swap” white and black pixels without kludging yet. I understand that LVGL isn’t primarily intended for monochrome displays, but given that it offers support for them and is the only upstream graphics library provided by Zephyr, I believe this is a valid concern.
Hi,
Can’t you do something like this?
#define BLACK lv_color_hex(0xffffff);
#define WHITE lv_color_hex(0x000000);
...
lv_obj_set_style_bg_color(obj, BLACK, 0);
Other than that, a not too hack solution could be to get the flush_cb
of the display that Zephyr created, set you own flush_cb
in which you invert the colors (should be fast for a small display:
for(...) {color_p[i] = ~color_p[i]; }
) and call the original flush_cb
in the end.
Manually defining black/white is what I have currently implemented in FW, along with setting dark theme so the other style variables are adjusted accordingly. I’m not sure if there’s an easy way to modify the flush_cb function without changing upstream code or creating a full wrapper for the original driver library.