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? To my understanding, the C formats are paletted, which would also fit very nicely semantically. You have an enumerated list of pixel values and each of them produces some arbitrary color on screen. This would fit e.g. blue/white LCD panels nicely. The little problem there is the palette. C8 format is traditionally translated to RGB triplets through GAMMA LUT. Therefore the display itself is still three-channel, it's just the framebuffer format that is single-channel. But now, we are dealing with truly paletted displays. Furthermore, the palette is fixed, ingrained in the panel hardware. So we would probably need a new KMS property for the fixed palette of the panel. What would it be called? Would it be a connector property? The property would be a read-only blob, an array that maps Cx values to "colors". How do we represent "colors"? How do we accommodate C1, C2, C4 and C8 with the same blob? Since the blob is a mapping from color index to "color", and the array in the blob has N entries, we could simply say that Cx integer value is the color index. If the Cx you use does not go up to N, then you miss some colors. If the Cx you use can go higher than N, then Cx values >= N will clamp to N-1, for example. Of course, if your panel palette has only 4 entries, you can expose C1 and C2 and have no reason to expose C4 or C8, avoiding the Cx >= N issue. How do we define the array contents then, the "colors"... plain old RGB triplets do not mean much[1], but that would be better than nothing. I also suppose that people would not be keen on seeing something like CIE 1931 XYZ or Lab values, even though those would probably have the most useful definition. Coming up with those values properly would require a colorimeter. As a compromise, maybe we could use an RGB triplet, and assume sRGB SDR color space and transfer function, just like we do with all displays whether they are that or not. If someone needs to know better, then they can profile the display. sRGB triplets would likely give enough intuition to what color the indices result in, that it could be used in automated color conversions or quantizations from larger color spaces like sRGB with some rough degree of color similarity. It is a lot of hassle, but it would have a clear benefit: userspace would know very well how the display behaves (what colors it shows, roughly), and you could use Cx formats to drive a panel in its "native" format. Possible problems are around interactions with the old GAMMA property, which is traditionally used for the C8 palette. But if you have a fixed-palette panel, then maybe you wouldn't expose GAMMA property on the CRTC at all? I have no idea how this would map to fbdev API though. [1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/pixels_color.md Thanks, pq > 2) Rx (single-channel for grayscale) > 3) RxGxBxAx (4-channel fake 32-bpp truecolor) > > The format preference will be in that order, so if user-space is able > to use Dx then there won't be a need for any conversion and just the > native format will be used. > > If using Rx then only a Rx -> Dx conversion will happen and the last > format will require the less performant RxGxBxAx -> Rx -> Dx path. > > But we still need RxGxBxAx as a fallback for compatibility with the > existing user-space, so all this could be done as a follow-up as an > optimization and shouldn't block monochromatic panel drivers IMO. > > Best regards,
Attachment:
pgp0ht3jcCqlM.pgp
Description: OpenPGP digital signature
