linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).