[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWWzE-ADAfXiNxbDOSur5n5zF1NkcB7Pab0_pq2-Q85=A@mail.gmail.com>
Date: Tue, 29 Apr 2025 08:39:50 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Marcus Folkesson <marcus.folkesson@...il.com>
Cc: David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Thomas Zimmermann <tzimmrmann@...e.de>,
Javier Martinez Canillas <javierm@...hat.com>
Subject: Re: [PATCH v6 2/3] drm/st7571-i2c: add support for Sitronix ST7571
LCD controller
Hi Marcus,
On Tue, 29 Apr 2025 at 08:15, Marcus Folkesson
<marcus.folkesson@...il.com> wrote:
> On Thu, Apr 24, 2025 at 10:38:33AM +0200, Geert Uytterhoeven wrote:
>
> [...]
>
> > > + /*
> > > + * As the display supports grayscale, all pixels must be written as two bits
> > > + * even if the format is monochrome.
> > > + *
> > > + * The bit values maps to the following grayscale:
> > > + * 0 0 = White
> > > + * 0 1 = Light gray
> > > + * 1 0 = Dark gray
> > > + * 1 1 = Black
> >
> > That is not R2, but D2?
> > include/uapi/drm/drm_fourcc.h:
> >
> > /* 2 bpp Red (direct relationship between channel value and brightness) */
> > #define DRM_FORMAT_R2 fourcc_code('R', '2', ' ', ' ')
> > /* [7:0] R0:R1:R2:R3 2:2:2:2 four pixels/byte */
> >
> > /* 2 bpp Darkness (inverse relationship between channel value and
> > brightness) */
> > #define DRM_FORMAT_D2 fourcc_code('D', '2', ' ', ' ')
> > /* [7:0] D0:D1:D2:D3 2:2:2:2 four pixels/byte */
> >
> > So the driver actually supports D1 and D2, and XRGB8888 should be
> > inverted while converting to monochrome (and grayscale, which is not
> > yet implemented).
>
> The display supports "reverse" grayscale, so the mapping becomes
> 1 1 = White
> 1 0 = Light gray
> 0 1 = Dark gray
> 0 0 = Black
> instead.
>
> So I will probably add support for D1 and D2 formats and invert the
> pixels for the R1, R2 and XRGB8888 formats.
>
> Could that work or are there any side effects that I should be aware of?
That should work fine.
Note that you do not have to support R1 and R2, as they are non-native.
AFAIK XRGB8888 is the only format all drivers must support.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists