Hi Pekka,
On Wed, Feb 2, 2022 at 10:20 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote:
> On Tue, 1 Feb 2022 12:07:07 +0100
> Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > 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.
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@xxxxxxxxxxxxxx
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
