On Tue, 15 Feb 2022 17:52:19 +0100 Geert Uytterhoeven geert@linux-m68k.org wrote:
Introduce fourcc codes for color-indexed frame buffer formats with two, four, and sixteen color, and provide a suitable mapping from bit per pixel and depth to fourcc codes.
As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch.
Signed-off-by: Geert Uytterhoeven geert@linux-m68k.org
Do we want to keep the rounding down if depth < bpp, or insist on depth == bpp? I don't think the rounding down will still be needed after "[PATCH 4/8] drm/client: Use actual bpp when allocating frame buffers".
drivers/gpu/drm/drm_fourcc.c | 18 ++++++++++++++++++ include/uapi/drm/drm_fourcc.h | 3 +++ 2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c index 07741b678798b0f1..60ce63d728b8e308 100644 --- a/drivers/gpu/drm/drm_fourcc.c +++ b/drivers/gpu/drm/drm_fourcc.c @@ -46,6 +46,18 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth) case 8: if (depth == 8) fmt = DRM_FORMAT_C8;
fallthrough;case 4:
if (depth == 4)fmt = DRM_FORMAT_C4;fallthrough;case 2:
if (depth == 2)fmt = DRM_FORMAT_C2;fallthrough;case 1:
if (depth == 1)fmt = DRM_FORMAT_C1;break;
case 16:
@@ -132,6 +144,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format); const struct drm_format_info *__drm_format_info(u32 format) { static const struct drm_format_info formats[] = {
{ .format = DRM_FORMAT_C1, .depth = 1, .num_planes = 1,.char_per_block = { 1, }, .block_w = { 8, }, .block_h = { 1, }, .hsub = 1, .vsub = 1 },{ .format = DRM_FORMAT_C2, .depth = 2, .num_planes = 1,.char_per_block = { 1, }, .block_w = { 4, }, .block_h = { 1, }, .hsub = 1, .vsub = 1 },{ .format = DRM_FORMAT_C4, .depth = 4, .num_planes = 1,.char_per_block = { 1, }, .block_w = { 2, }, .block_h = { 1, }, .hsub = 1, .vsub = 1 },diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index fc0c1454d2757d5d..3f09174670b3cce6 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -99,6 +99,9 @@ extern "C" { #define DRM_FORMAT_INVALID 0
/* color index */ +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /* [0] C */ +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /* [1:0] C */ +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /* [3:0] C */
Hi Geert,
generally this looks fine to me though I'm not familiar with the code. The thing I'm missing here is a more precise description of the new pixel formats.
#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
This description of C8 is a little vague maybe, but presumably one pixel being one byte, the address of pixel x is just &bytes[x].
C4, C2 and C1 should also specify the pixel order within the byte. There is some precedent of that in with some YUV formats in this file.
Maybe something like:
C2 /* [7:0] c0:c1:c2:c3 2:2:2:2 four pixels per byte */
or the other way around, which ever your ordering is?
Thanks, pq