linux-kernel - Re: [PATCH v6 2/3] drm/st7571-i2c: add support for Sitronix ST7571 LCD controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87zffzza55.fsf@minerva.mail-host-address-is-not-set>
Date: Tue, 29 Apr 2025 09:42:30 +0200
From: Javier Martinez Canillas <javierm@...hat.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>, 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>
Subject: Re: [PATCH v6 2/3] drm/st7571-i2c: add support for Sitronix ST7571
 LCD controller

Geert Uytterhoeven <geert@...ux-m68k.org> writes:

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

Agree.

> 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,
>

That's correct. The driver should only support D1 and D2 as native formats
and (emulated) XRGB8888 for compatibility with existing user-space. No need
to support R1 and R2 since the controller does not support these formats.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat