linux-kernel - Re: [PATCH v2 RFC 08/10] drm/fourcc: Document that single-channel "red" can be any color

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 8 Mar 2022 11:06:43 +0200
From:   Pekka Paalanen <ppaalanen@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Sam Ravnborg <sam@...nborg.org>, Helge Deller <deller@....de>,
        linux-fbdev@...r.kernel.org, linux-m68k@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 RFC 08/10] drm/fourcc: Document that single-channel
 "red" can be any color

On Mon,  7 Mar 2022 21:52:43 +0100
Geert Uytterhoeven <geert@...ux-m68k.org> wrote:

> Traditionally, the first channel has been called the "red" channel, but
> the fourcc values for single-channel "red" formats can also be used for
> other light-on-dark displays, like grayscale.
> 
> Signed-off-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> ---
> RFC, as I have no immediate need for these formats.
> 
> v2:
>   - New.
> ---
>  include/uapi/drm/drm_fourcc.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 457ed39cc48f08e1..f0187cf20e4619d2 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -104,16 +104,16 @@ extern "C" {
>  #define DRM_FORMAT_C4		fourcc_code('C', '4', ' ', ' ') /* [7:0] C0:C1 4:4 two pixels/byte */
>  #define DRM_FORMAT_C8		fourcc_code('C', '8', ' ', ' ') /* [7:0] C 8 one pixel/byte */
>  
> -/* 8 bpp Red */
> +/* 8 bpp Red (or generic light-on-dark) */
>  #define DRM_FORMAT_R8		fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
>  
> -/* 10 bpp Red */
> +/* 10 bpp Red (or generic light-on-dark) */
>  #define DRM_FORMAT_R10		fourcc_code('R', '1', '0', ' ') /* [15:0] x:R 6:10 little endian */
>  
> -/* 12 bpp Red */
> +/* 12 bpp Red (or generic light-on-dark) */
>  #define DRM_FORMAT_R12		fourcc_code('R', '1', '2', ' ') /* [15:0] x:R 4:12 little endian */
>  
> -/* 16 bpp Red */
> +/* 16 bpp Red (or generic light-on-dark) */
>  #define DRM_FORMAT_R16		fourcc_code('R', '1', '6', ' ') /* [15:0] R little endian */
>  
>  /* 16 bpp RG */

Hi Geert,

this is a good idea. I just wonder whether light-on-dark is an accurate
description. To me, light-on-dark means things like bright characters
on a dark background, but that is a property of the image as a whole and
not a property of the pixel format. What I think you are after here is
that increasing channel value mean increasing brightness.

How to word that concisely...

Direct relationship to brightness (vs. inverse relationship to brightness)?

This does not imply a linear relationship, and I'd also use
"brightness" to denote that it is a qualitative factor relating to
human observation.


Thanks,
pq

Content of type "application/pgp-signature" skipped