From: "Noralf Trønnes" <noralf@tronnes.org>
To: Peter Stuge <peter@stuge.se>
Cc: dri-devel@lists.freedesktop.org, hudson@trmm.net,
markus@raatikainen.cc, sam@ravnborg.org,
linux-usb@vger.kernel.org, th020394@gmail.com, lkundrak@v3.sk,
pontus.fuchs@gmail.com, Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH v6 3/3] drm: Add GUD USB Display driver
Date: Thu, 25 Feb 2021 19:06:40 +0100 [thread overview]
Message-ID: <ecd868f9-5877-63ea-7d3b-504147489b61@tronnes.org> (raw)
In-Reply-To: <20210225095825.6196.qmail@stuge.se>
Den 25.02.2021 10.58, skrev Peter Stuge:
> Hi Noralf,
>
> Noralf Trønnes wrote:
>> The driver supports a one bit monochrome transfer format: R1. This is not
>> implemented in the gadget driver. It is added in preparation for future
>> monochrome e-ink displays.
>
> I forgot, but I have a two-tone (black/red) e-ink display here, and I
> also have a 3-bpp RGB TFT display.
>
> Should we add maybe R2 and R3? (or R3/R8 for number of colours?)
>
> I'm particularly considering the 3-bpp RGB panel for GUD use now, and
> while it will surely work with say a 16-bit RGB mode many bits will
> be wasted in the process.
>
> What are your thoughts? Would you take a patch for that now, later, never?
>
I've been anticipating the need for more formats, but I didn't want to
add them without having a user. Otherwise I could end up adding stuff
that would never be used. If you can test, there's no problem adding
support for more formats now.
The R1 name is derived from DRM_FORMAT_R8 which is a 8 bit monochrome
(or one color channel) format.
Linux has these one byte color pixel formats currently defined:
/* color index */
#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
/* 8 bpp Red */
#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
/* 8 bpp RGB */
#define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
3:3:2 */
#define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
2:3:3 */
And these two color formats:
/* 16 bpp RG */
#define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /* [15:0] R:G
8:8 little endian */
#define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /* [15:0] G:R
8:8 little endian */
/* 32 bpp RG */
#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
16:16 little endian */
#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 little endian */
Building on that I would define a 2 bpp RG format like this in the driver:
static const struct drm_format_info gud_drm_format_rg11 = {
.format = GUD_DRM_FORMAT_RG11,
.num_planes = 1,
.char_per_block = { 1, 0, 0 },
.block_w = { 4, 0, 0 }, /* 4 pixels per block/byte */
.block_h = { 1, 0, 0 },
.hsub = 1,
.vsub = 1,
};
And a 3 bpp RGB format like this:
static const struct drm_format_info gud_drm_format_rgb111 = {
.format = GUD_DRM_FORMAT_RGB111,
.num_planes = 1,
.char_per_block = { 1, 0, 0 },
.block_w = { 2, 0, 0 }, /* 2 pixels per block/byte */
.block_h = { 1, 0, 0 },
.hsub = 1,
.vsub = 1,
};
The MIPI DBI standard defines 2 ways to transmit 2x 3-bpp pixels in one
byte (X=pad bit):
- Option 1: X X R1 G1 B1 R2 G2 B2
- Option 2: X R1 G1 B1 X R2 G2 B2
So maybe we should have GUD_DRM_FORMAT_RGB111_OPTION1 and
GUD_DRM_FORMAT_RGB111_OPTION2?
Or just use option 2 and let the display fix it up if needed?
What format does your 3 bpp display use?
And then something like this for the conversion function:
static size_t gud_xrgb8888_to_color(u8 *dst, const struct
drm_format_info *format,
u32 *src, struct drm_framebuffer *fb,
struct drm_rect *rect)
{
unsigned int block_width = drm_format_info_block_width(format, 0);
unsigned int x, y, width, height;
u8 r, g, b, *block = dst; /* Assign to silence compiler warning */
size_t len;
WARN_ON_ONCE(format->char_per_block[0] != 1);
/* Start on a byte boundary */
rect->x1 = ALIGN_DOWN(rect->x1, block_width);
width = drm_rect_width(rect);
height = drm_rect_height(rect);
len = drm_format_info_min_pitch(format, 0, width) * height;
for (y = 0; y < height; y++) {
for (x = 0; x < width; x++) {
if (!(x % block_width)) {
block = dst++;
*block = 0;
}
/* r,g,b are bytes so no need to mask out anything explicitly */
r = *src >> 16;
g = *src >> 8;
b = *src++;
switch (format->format) {
case GUD_DRM_FORMAT_RG11:
*block <<= 2;
*block |= ((r >> 7) << 1) | (g >> 7);
break;
case GUD_DRM_FORMAT_RGB111_OPTION1:
*block <<= 3;
*block |= ((r >> 7) << 2) | ((g >> 7) << 1) | (b >> 7);
break;
case GUD_DRM_FORMAT_RGB111_OPTION2:
*block <<= 4;
*block |= ((r >> 7) << 2) | ((g >> 7) << 1) | (b >> 7);
break;
default:
WARN_ON_ONCE(1);
return len;
};
}
}
return len;
}
Noralf.
next prev parent reply other threads:[~2021-02-25 18:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 12:16 [PATCH v6 0/3] GUD USB Display driver Noralf Trønnes
2021-02-19 12:17 ` [PATCH v6 1/3] drm/uapi: Add USB connector type Noralf Trønnes
2021-02-19 12:17 ` [PATCH v6 2/3] drm/probe-helper: Check epoch counter in output_poll_execute() Noralf Trønnes
2021-02-19 12:17 ` [PATCH v6 3/3] drm: Add GUD USB Display driver Noralf Trønnes
2021-02-19 21:42 ` Peter Stuge
2021-02-20 17:27 ` Noralf Trønnes
2021-02-26 12:09 ` Noralf Trønnes
2021-02-28 1:52 ` Peter Stuge
2021-02-28 21:04 ` Noralf Trønnes
2021-02-25 9:58 ` Peter Stuge
2021-02-25 18:06 ` Noralf Trønnes [this message]
2021-02-25 21:37 ` Peter Stuge
2021-02-26 12:18 ` Noralf Trønnes
[not found] ` <20210225213729.GG20076@stuge.se>
2021-03-01 18:31 ` Peter Stuge
2021-03-01 21:41 ` Noralf Trønnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ecd868f9-5877-63ea-7d3b-504147489b61@tronnes.org \
--to=noralf@tronnes.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hudson@trmm.net \
--cc=linux-usb@vger.kernel.org \
--cc=lkundrak@v3.sk \
--cc=markus@raatikainen.cc \
--cc=peter@stuge.se \
--cc=pontus.fuchs@gmail.com \
--cc=sam@ravnborg.org \
--cc=th020394@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).