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

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Pekka,

On Wed, Feb 2, 2022 at 10:20 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> On Tue, 1 Feb 2022 12:07:07 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Feb 1, 2022 at 11:42 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > > On Tue, 1 Feb 2022 10:49:03 +0100
> > > Javier Martinez Canillas <javierm@redhat.com> wrote:
> > > > On 2/1/22 09:38, Daniel Vetter wrote:
> > > > > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser <contact@emersion.fr> wrote:
> > > > >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven <geert@linux-m68k.org> 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.

Fbdev has separate (orthogonal) settings for
  1. Frame buffer layout (FB_TYPE_*),
  2. Pixel format (depth and fb_bitfields),
  3. Visual.
DRM combines all of the above in a fourcc value.

Nowadays most frame buffer layouts are packed, so using a shadow
frame buffer to support other layouts is very helpful, as it means
applications no longer have to care about legacy frame buffer layouts.

> 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

Agreed, the only thing that matters is a monotonic mapping, and
whether it's increasing or decreasing.

> should be dealt with - or just have the driver invert the pixel values
> before sending them to display?

That's an option. If the data has to be copied anyway, inversion is
a cheap operation. Else I think you need new fourcc types.

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

Yeah, it's complicated, but rather rare. Most desktop hardware
(even from the nineties ;-) does support a programmable palette.
Exceptions are CGA, the C64 (no Linux support yet ;-), and eInk
displays that support e.g. white, black, and red.

If you do want to support it, perhaps introduce Fx (F = fixed)
fourcc types?

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

Fine, as said above, monotonic mapping is what matters.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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