Support for ARGB2222

Feature request
1

Hi there,

As far as I can see, there is no direct support for ARGB2222 in lvgl. What would be the easiest way to add it?

Thanks!

2

If you have a small display you can use set_px_cb for custom color formats.

3

As best I can tell, using scaled back versions of ARGB8888 (i.e. ARGB4444, ARGB2222) requires packing and unpacking as a part of set_px_cb. I am using ARGB4444 on a project, and pack down the color to store into the buffer on OPA_COVER, and then unpack the buffer contents to mix colors (lv_color_mix) and repack the result if there is a blend. This comes with a performance penalty.

Given the DMA2D of the STM32’s support for ARGB4444 and ARGB1555, I think it may make sense to have native support for handling colors of these types. Would you consider adding support to the mainline if it was provided as a contribution?

4

ARGB4444 and ARGB1555 are easy to handle as they can be packed to uint16_t and at first look, it requires updates only in lv_color.h.

So I’m open to adding support to these formats. If you are interested please open an issue or a pull request for it on GitHub.

I added this to ROADMAP.

5

Just wanted to give some feedback, as I’ve tried implementing this locally, and have run into some problems along the way. What I have, I would definitely describe as a hack. The library makes certain assumptions when your LV_COLOR_DEPTH is 16 that required the bulk of what I would consider the hacks. I believe I had the implementation mostly correct (in terms of functionality), but the last issue I was facing was related to image data formats.
What I was doing ended up pretty messy, because there were stacked conditionals, with LV_COLOR_DEPTH = 32 or LV_COLOR_DEPTH 16 and LV_COLOR_16_ALPHA, plus LV_COLOR_DEPTH = 16 had mutually exclusive options for both LV_COLOR_16_SWAP and LV_COLOR_16_ALPHA. If you would like, I can rebase the hacks on the latest and get it somewhere that you could inspect.
If I were doing this properly, I would suggest changing the entire handling of LV_COLOR_DEPTH/LV_COLOR_16_SWAP and instead use an LV_COLOR_FORMAT with values for 32 bit ARGB, 16 bit RGR565, swapped 16, ARGB4444, RGB332, ARGB2222, M1. I’d craft those values to have some flag bits and data width encoded in them, so that you can easily check with a HAS_ALPHA(…) macro, COLOR_WIDTH(…), etc.
In the end, I had to abandon working on this due to other priorities, and we’re getting by with ARGB8888 internally with conversion just before sending to the display in the flush_cb.

6

Hi,

I agree that that the current LV_COLOR_DEPTH + LV_COLOR_16_SWAP is not flexible enough. A plain RGB888 is also missing from LVGL yet.

However, the good news is it’s on the roadmep to rework the color format management.