CFB Enhancement

[soburi]

I propose enhancing CFB.

Currently, CFB only supports monochrome displays.
I will add support for color display.
We usually utilize LVGL for this purpose in Zephyr, which is the ideal solution in many cases.
However, it may not work by the reasons that memory or footprint size for highly resource-constrained devices.
CFB has only minimal drawing functionality. We can operate relatively well in such environments.
In other words, this feature addition attempts to provide a minimum level of graphics support that we can use universally in the environment in which Zephyr operates.

The changes have become a long series of patches, so I divided them into several PRs.
I have divided the commits into four PRs and ordered based on importance and fundamentalness.

1. Bug fix and implementation improvements

   • Bug fixes, Add tests. fb: cfb: Fix CFB_FONT_MSB_FIRST font rendering #67881
   • Improve missing font handling fb: cfb: Improve handling of missing characters in font #85434
   • Remove unused Kconfig option fb: cfb: Remove unused config #85435
   • Remove font size restrictions fb: cfb: Remove restriction on fonts with non-multiple-of-8 heights #85436

2. Supporting multi-display (API Changing)

   • Remove unused argument fb: cfb: Remove unused argument from font API #85442
   • Use signed values for the coordinates fb: cfb: Use signed-integer for API that specifies coordinations #85443
   • Multiple display support fb: cfb: Supporting multiple display #68260

3. Supporting color-display and Related stuff updating

   • Color display support fb: cfb: Support color display #58817

This makes CFB no longer a "(Monochrome) Character" Framebuffer, but the API remains essentially unchanged. Therefore, we will rename it "Compact" Framebuffer to use the same abbreviation.

5. Support for memory-constrained environments

   • Reduce memory consumption by partial frame transferring fb: cfb: Support memory constrainted system by partial frame transferring #72204

CFB is an implementation that allocates a buffer that can store the entire screen, but this uses a lot of memory. Works with less memory by splitting the screen and rendering and transmitting multiple times when memory is low.
To achieve this, we introduce a mechanism that expresses drawing operations as a command data structure and executes them as a type of lazy evaluation. For this, we add a buffer for the command.

[rruuaanng]

@soburi Do you currently have time to continue working on #58817? Recently, I wanted to use CFB to display simple text on the ST7735S, but it appears to only support monochrome black-and-white displays. The screen module I'm using operates in the 565 color space, and when I tried using CFB, the screen did not respond at all.
(Or perhaps, the lack of text display on the screen is due to an error in my code.)

[soburi]

@soburi Do you currently have time to continue working on #58817? Recently, I wanted to use CFB to display simple text on the ST7735S, but it appears to only support monochrome black-and-white displays. The screen module I'm using operates in the 565 color space, and when I tried using CFB, the screen did not respond at all. (Or perhaps, the lack of text display on the screen is due to an error in my code.)

So let's rebooting...
But, unless you are tightly memory-constrained, I generally recommend using LVGL.

[rruuaanng]

If possible, that would be great! Actually, it's just that I want to use it. I'm not very familiar with LVGL, but for some of the unfinished tasks mentioned above, I will take a serious look at them in my free time and try to make some progress.

[soburi]

In reality, there have been no major issues with the implementation except for the last enhancement, and we think the challenge is to reach an agreement on the API changes.

However, if the enhancements are not foreseeable to a certain extent, there remains the possibility that "additional API changes" will occur, so this needs to be agreed upon at the design stage. This work is delayed.