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