Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Jul 24, 2019 at 2:52 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Jul 23, 2019 at 11:07 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Tue, Jul 23, 2019 at 7:25 PM Adam Jackson <ajax@redhat.com> wrote:
> > >
> > > On Tue, 2019-07-23 at 15:37 +0200, Linus Walleij wrote:
> > > > Migrating the TI nspire calculators to use the PL111 driver for
> > > > framebuffer requires grayscale support for the elder panel
> > > > which uses 8bit grayscale only.
> > > >
> > > > DRM does not support 8bit grayscale framebuffers in memory,
> > > > but by defining the bus format to be MEDIA_BUS_FMT_Y8_1X8 we
> > > > can get the hardware to turn on a grayscaling feature and
> > > > convert the RGB framebuffer to grayscale for us.
> > >
> > > What's wrong with DRM_FORMAT_R8? Yes the hardware is not really
> > > "redscale", but it's still a single color channel and there's not
> > > really any ambiguity.
> >
> > Yeah, I think with a comment or an aliasing #define to _Y8 (or both)
> > this is good to go.
>
> Is there something really wrong with just biting the bullet and do this:
>
> /* 8 bpp grayscale */
> #define DRM_FORMAT_Y8 fourcc_code('Y', '8', ' ', ' ') /* [7:0] Y */
>
> It's quite an embarrasement for my OCD tendencies to talk about
> black-and-white TV as if it was 256 Shades of Red (good title
> for a novel by the way).
>
> I don't know how these FOURCC things work, possibly new
> fourcc:s can only be defined by some especially enlightened
> cabal of standardization?
>
> (It beats me how it can not already exist in that case.)

The drm subsystem cabal owns drm_fourcc.h. And yeah I guess we can
also add Y version of all these, I think the R/RG was added since that
matches modern GL, where your texture contents are entirely up to
interpretation by shaders. Y also exists in GL, but only in legacy
contexts and is kinda discouraged. That was the idea behind just
making them aliasing (since I just can't come up with any reason why
you'd actually want a red-only texture). In a way R = red = the first
channel in GL shaders, which happens to be called r for red !=
actually red color channel on the display.

Hence we might as well state that if you give a kms driver a
single-channel fourcc code, then that should be interpreted as
greyscale. Plus add a huge comment about why this single channel is
called R :-)
-Daniel

> > You probably still want to expose the rgb format since too much
> > userspace just assumes that xrgb8888 works. Same reason why the
> > tinydrm drivers do the sw conversion.
>
> Yes this is what we do on PL111 now, we just run it through
> the hardware grayscaler.
>
> This hardware graciously supports reading black-white and
> grayscale bitmaps with 1 (monochrome), 2, 4 and 8 bits per
> pixel which would be Y1, Y2, Y4 and Y8. But we only have
> hardware supporting Y8 at least on the other side so
> I don't see any need for the others ATM.
>
> I suspect the Y1 etc could be useful for people doing not
> only Hercules video drivers (hah!) but also for ePaper
> displays of say, some random Kindle.

I guess if we bother with Y (whether aliased to R or new ones) we
might as well roll out all of them.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel