Support 16/32 bit color depth

[p96114175]

Mado currently uses 32-bit bpp, supporting display devices on desktop/laptop computers, while Raspberry Pi devices use 16-bit bpp. To improve mado’s compatibility across various Linux framebuffer environments, testing showed that
tx->fb_var.bits_per_pixel automatically sets the appropriate bpp without requiring manual configuration.

[p96114175]

The current demo-fbdev can output on Raspberry Pi devices, but the display output is not normal. The result is as shown in the image.

[jserv]

The current demo-fbdev can run on Raspberry Pi devices, but the display output is not normal.

Each RGB565 pixel requires 2 bytes. Typically, when using 16 bits per pixel, these bits are split to represent red, green, and blue values packed into a 16-bit word, with RGB565 as the standard format. In this layout, 5 bits are allocated to red, 6 to green, and 5 to blue, with red occupying the most significant bits in framebuffer memory. However, determining whether these bytes are stored in big-endian or little-endian format in memory can be challenging.

This means that, after arranging R, G, and B values into a 16-bit word in the application, you may need to swap the bytes if the endianness of the CPU differs from that of the display device.

To convert 8-bit R, G, and B color values to a 16-bit RGB565 format for Mado, you can use a function like this:

static uint16_t rgb888_to_rgb565(uint8_t r, uint8_t g, uint8_t b)
{
    return (((uint16_t)r & 0xF8) << 8) | (((uint16_t)g & 0xFC) << 3) | (b >> 3);
}

Pixman would be useful for providing the accelerated routines for such purpose.

This conversion function provides color translation for Mado's framebuffer backend.
Reference:

• Using the Linux framebuffer in C/C++: Part 1
• Using the Linux framebuffer in C/C++: Part 2
• Framebuffer (Linux)

This pull request has been converted to a draft as further rework is required.