Re: [PATCH 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays

[Pekka Paalanen]

On Tue, 1 Feb 2022 12:07:07 +0100
Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:

> Hi Pekka,
> 
> On Tue, Feb 1, 2022 at 11:42 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote:
> > On Tue, 1 Feb 2022 10:49:03 +0100
> > Javier Martinez Canillas <javierm@xxxxxxxxxx> wrote:  
> > > On 2/1/22 09:38, Daniel Vetter wrote:  
> > > > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@xxxxxxxxxxx> wrote:  
> > > >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:  
> > > >>> What's the story with the Rn formats?
> > > >>>
> > > >>> The comments say "n bpp Red", while this is a monochrome (even
> > > >>> inverted) display?  
> > > >>
> > > >> I don't think the color matters that much. "Red" was picked just because it was
> > > >> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?  
> > > >
> > > > The red comes from gl, where with shaders it really doesn't matter
> > > > what meaning you attach to channels, but really just how many you
> > > > have. So 2-channel formats are called RxGx, 3-channel RxGxBx,
> > > > 4-channel RxGxBxAx and single-channel Rx. And we use drm_fourcc for
> > > > interop in general, hence why these exist.
> > > >
> > > > We should probably make a comment that this really isn't a red channel
> > > > when used for display it's a greyscale/intensity format. Aside from
> > > > that documentation gap I think reusing Rx formats for
> > > > greyscale/intensity for display makes perfect sense.
> > > > -Daniel  
> > >
> > > To sump up the conversation in the #dri-devel channel, these drivers
> > > should support the following formats:
> > >
> > > 1) Dx (Daniel suggested that for darkness, but inverted mono)  
> >
> > Did you consider format C1 instead?  
> 
> That would be a 2-color display, which is not necessarily black
> and white. Cfr. Amiga or Atari bit planes with bpp=1.
> That's why fbdev has separate visuals for monochrome.

Yes, that is exactly what I was aiming at: to draft a plan for panels
that have a fixed and arbitrary palette. From the discussions I
understood that the panel in question here requires somehow reversed
colors ("inverted mono"), which didn't really sound to be like "normal
monochrome".

> > I have no idea how this would map to fbdev API though.  
> 
>     #define FB_VISUAL_MONO01                0       /* Monochr.
> 1=Black 0=White */
>     #define FB_VISUAL_MONO10                1       /* Monochr.
> 1=White 0=Black */
>     #define FB_VISUAL_TRUECOLOR             2       /* True color   */
> 
> The above is RGB (or grayscale, see below).
> 
>     #define FB_VISUAL_PSEUDOCOLOR           3       /* Pseudo color
> (like atari) */
> 
> Palette
> 
>     #define FB_VISUAL_DIRECTCOLOR           4       /* Direct color */
> 
> Usually used as RGB with gamma correction, but the actual hardware
> is more flexible.
> 
>     #define FB_VISUAL_STATIC_PSEUDOCOLOR    5       /* Pseudo color readonly */
> 
> Fixed palette
> 
> And:
> 
>     struct fb_var_screeninfo {
>             ...
>             __u32 grayscale;                /* 0 = color, 1 = grayscale,    */

DRM has pixel formats, but no visuals so far. Maybe it needs to grow
the concept of visuals in some form? However, care should be taken to
not clash with existing colorimetry features. I would hope that the
colorimetry feature set could be extended to cover the above as well.
Well, only if there would be any users for it.

My silly attempt with Cx formats (e.g. DRM_FORMAT_C8) was a stab in that
direction, but maybe not flexible enough for the above.

If on the other hand the panel is "grayscale" but with an arbitrary
color (white, green, orange or other on black), the IRC consensus seems
to be that one should use Rx formats (e.g. DRM_FORMAT_R8) for it,
regardless of the actual color. That would convey that the pixel value
has a monotonic (increasing) mapping to brightness, unlike with
paletted formats. I agree with this, but wonder how reversed brightness
should be dealt with - or just have the driver invert the pixel values
before sending them to display?

Cx formats with a read-only palette could be used to represent
"grayscale" and "reversed grayscale" too, but people seem to think that
is too complicated to analyse and use for KMS userspace.

Other #dri-devel IRC mumblings were about maybe adding a DRM pixel
format for grayscale or intensity or luminance so that one would not
need to use "red" color channel for something that doesn't look red.
That is, do not use Cx formats because those produce completely
arbitrary colors, and do not use Rx formats because the display is not
redscale. Personally I'd be fine with Rx formats.


Thanks,
pq

Attachment: pgpzc9P82Gcyj.pgp
Description: OpenPGP digital signature