All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Fabian Vogt <fabian@ritter-vogt.de>,
	Daniel Tang <dt.tangr@gmail.com>, Adam Jackson <ajax@redhat.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
Date: Wed, 24 Jul 2019 14:52:19 +0200	[thread overview]
Message-ID: <CACRpkdZWpRFN7=m+XRUbYLjAUxygwHZ6ehKEK+7nmPxSKY0o9w@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uHVudGdTzQS3Q6qVTZtDU-UsSQ2K04M9VvZHxzXo0DHOw@mail.gmail.com>

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.)

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

Yours,
Linus Walleij

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

WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Fabian Vogt <fabian@ritter-vogt.de>,
	Daniel Tang <dt.tangr@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
Date: Wed, 24 Jul 2019 14:52:19 +0200	[thread overview]
Message-ID: <CACRpkdZWpRFN7=m+XRUbYLjAUxygwHZ6ehKEK+7nmPxSKY0o9w@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uHVudGdTzQS3Q6qVTZtDU-UsSQ2K04M9VvZHxzXo0DHOw@mail.gmail.com>

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.)

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

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-07-24 12:52 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-23 13:37 [PATCH 0/3] RFT: PL111 DRM conversion of nspire Linus Walleij
2019-07-23 13:37 ` Linus Walleij
2019-07-23 13:37 ` [PATCH 1/3] RFT: drm/pl111: Support grayscale Linus Walleij
2019-07-23 13:37   ` Linus Walleij
2019-07-23 15:19   ` Fabian Vogt
2019-07-23 15:19     ` Fabian Vogt
2019-07-24 12:33     ` Linus Walleij
2019-07-24 12:33       ` Linus Walleij
2019-07-25 19:26       ` Fabian Vogt
2019-07-25 19:26         ` Fabian Vogt
2019-08-03  9:51         ` Linus Walleij
2019-08-03  9:51           ` Linus Walleij
2019-08-04 20:13           ` Fabian Vogt
2019-08-04 20:13             ` Fabian Vogt
2019-07-23 16:22   ` [1/3] " David Lechner
2019-07-23 16:22     ` David Lechner
2019-07-23 17:25   ` [PATCH 1/3] " Adam Jackson
2019-07-23 17:25     ` Adam Jackson
2019-07-23 21:06     ` Daniel Vetter
2019-07-23 21:06       ` Daniel Vetter
2019-07-24 12:52       ` Linus Walleij [this message]
2019-07-24 12:52         ` Linus Walleij
2019-07-24 14:06         ` Daniel Vetter
2019-07-24 14:06           ` Daniel Vetter
2019-07-23 13:37 ` [PATCH 2/3] RTF: drm/panel: simple: Add TI nspire panels Linus Walleij
2019-07-23 13:37   ` Linus Walleij
2019-07-23 17:54   ` Sam Ravnborg
2019-07-23 17:54     ` Sam Ravnborg
2019-07-24 13:58     ` Linus Walleij
2019-07-24 13:58       ` Linus Walleij
2019-07-24 18:53       ` Sam Ravnborg
2019-07-24 18:53         ` Sam Ravnborg
2019-07-23 13:37 ` [PATCH 3/3] RFT: ARM: nspire: Move CLCD set-up to device tree Linus Walleij
2019-07-23 13:37   ` Linus Walleij
2019-07-23 18:10 ` [PATCH 0/3] RFT: PL111 DRM conversion of nspire Sam Ravnborg
2019-07-23 18:10   ` Sam Ravnborg
2019-07-24 12:28   ` Linus Walleij
2019-07-24 12:28     ` Linus Walleij
2019-07-24 12:47     ` Pawel Moll
2019-07-24 12:47       ` Pawel Moll
2019-07-24 12:53       ` Linus Walleij
2019-07-24 12:53         ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACRpkdZWpRFN7=m+XRUbYLjAUxygwHZ6ehKEK+7nmPxSKY0o9w@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=ajax@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dt.tangr@gmail.com \
    --cc=fabian@ritter-vogt.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.