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