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) 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, -- Javier Martinez Canillas Linux Engineering Red Hat
