From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: Simon Glass <sjg@chromium.org>
Cc: kettenis@openbsd.org, u-boot@lists.denx.de, agust@denx.de,
xypron.glpk@gmx.de, agraf@csgraf.de
Subject: Re: [PATCH 1/3] video: Add 30bpp support
Date: Sat, 25 Sep 2021 18:55:16 +0200 (CEST) [thread overview]
Message-ID: <5614855b50ef76ab@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <CAPnjgZ1YkM72Kz1WJyCY4cs92zx-6hV3e+YCO57biP-TONdXnQ@mail.gmail.com> (message from Simon Glass on Sat, 25 Sep 2021 07:40:54 -0600)
> From: Simon Glass <sjg@chromium.org>
> Date: Sat, 25 Sep 2021 07:40:54 -0600
>
> On Thu, 16 Sept 2021 at 07:01, Mark Kettenis <kettenis@openbsd.org> wrote:
> >
> > Add support for 30bpp mode where pixels are picked in 32-bit
> > integers but use 10 bits instead of 8 bits for each component.
> >
> > Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> > ---
> > drivers/video/console_normal.c | 2 ++
> > drivers/video/console_rotate.c | 6 ++++++
> > drivers/video/console_truetype.c | 3 +++
> > drivers/video/vidconsole-uclass.c | 7 +++++++
> > drivers/video/video-uclass.c | 1 +
> > include/video.h | 1 +
> > 6 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/video/console_normal.c b/drivers/video/console_normal.c
> > index 04f022491e..e0b89cbb93 100644
> > --- a/drivers/video/console_normal.c
> > +++ b/drivers/video/console_normal.c
> > @@ -41,6 +41,7 @@ static int console_normal_set_row(struct udevice *dev, uint row, int clr)
> > end = dst;
> > break;
> > }
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32:
> > if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
> > uint32_t *dst = line;
> > @@ -126,6 +127,7 @@ static int console_normal_putc_xy(struct udevice *dev, uint x_frac, uint y,
> > }
> > break;
> > }
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32:
> > if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
> > uint32_t *dst = line;
> > diff --git a/drivers/video/console_rotate.c b/drivers/video/console_rotate.c
> > index 36c8d0609d..bf81b80a39 100644
> > --- a/drivers/video/console_rotate.c
> > +++ b/drivers/video/console_rotate.c
> > @@ -40,6 +40,7 @@ static int console_set_row_1(struct udevice *dev, uint row, int clr)
> > *dst++ = clr;
> > break;
> > }
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32:
> > if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
> > uint32_t *dst = line;
> > @@ -128,6 +129,7 @@ static int console_putc_xy_1(struct udevice *dev, uint x_frac, uint y, char ch)
> > }
> > break;
> > }
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32:
> > if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
> > uint32_t *dst = line;
> > @@ -183,6 +185,7 @@ static int console_set_row_2(struct udevice *dev, uint row, int clr)
> > end = dst;
> > break;
> > }
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32:
> > if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
> > uint32_t *dst = line;
> > @@ -266,6 +269,7 @@ static int console_putc_xy_2(struct udevice *dev, uint x_frac, uint y, char ch)
> > }
> > break;
> > }
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32:
> > if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
> > uint32_t *dst = line;
> > @@ -318,6 +322,7 @@ static int console_set_row_3(struct udevice *dev, uint row, int clr)
> > *dst++ = clr;
> > break;
> > }
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32:
> > if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
> > uint32_t *dst = line;
> > @@ -402,6 +407,7 @@ static int console_putc_xy_3(struct udevice *dev, uint x_frac, uint y, char ch)
> > }
> > break;
> > }
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32:
> > if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
> > uint32_t *dst = line;
> > diff --git a/drivers/video/console_truetype.c b/drivers/video/console_truetype.c
> > index 98427f4c61..0195d996de 100644
> > --- a/drivers/video/console_truetype.c
> > +++ b/drivers/video/console_truetype.c
> > @@ -153,6 +153,7 @@ static int console_truetype_set_row(struct udevice *dev, uint row, int clr)
> > }
> > #endif
> > #ifdef CONFIG_VIDEO_BPP32
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32: {
> > u32 *dst = line;
> >
> > @@ -299,6 +300,7 @@ static int console_truetype_putc_xy(struct udevice *dev, uint x, uint y,
> > }
> > #endif
> > #ifdef CONFIG_VIDEO_BPP32
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32: {
> > u32 *dst = (u32 *)line + xoff;
> > int i;
> > @@ -381,6 +383,7 @@ static int console_truetype_erase(struct udevice *dev, int xstart, int ystart,
> > }
> > #endif
> > #ifdef CONFIG_VIDEO_BPP32
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32: {
> > uint32_t *dst = line;
> >
> > diff --git a/drivers/video/vidconsole-uclass.c b/drivers/video/vidconsole-uclass.c
> > index 8132efa55a..cc274b45fe 100644
> > --- a/drivers/video/vidconsole-uclass.c
> > +++ b/drivers/video/vidconsole-uclass.c
> > @@ -153,6 +153,13 @@ u32 vid_console_color(struct video_priv *priv, unsigned int idx)
> > ((colors[idx].b >> 3) << 0);
> > }
> > break;
> > + case VIDEO_BPP30:
> > + if (CONFIG_IS_ENABLED(VIDEO_BPP32)) {
> > + return (colors[idx].r << 22) |
> > + (colors[idx].g << 12) |
> > + (colors[idx].b << 2);
> > + }
> > + break;
> > case VIDEO_BPP32:
> > if (CONFIG_IS_ENABLED(VIDEO_BPP32)) {
> > return (colors[idx].r << 16) |
> > diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
> > index 9f8cf6ef2a..28bf701f41 100644
> > --- a/drivers/video/video-uclass.c
> > +++ b/drivers/video/video-uclass.c
> > @@ -129,6 +129,7 @@ int video_clear(struct udevice *dev)
> > *ppix++ = priv->colour_bg;
> > break;
> > }
> > + case VIDEO_BPP30:
> > case VIDEO_BPP32:
> > if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
> > u32 *ppix = priv->fb;
> > diff --git a/include/video.h b/include/video.h
> > index 827733305e..04c636b317 100644
> > --- a/include/video.h
> > +++ b/include/video.
> > @@ -53,6 +53,7 @@ enum video_log2_bpp {
> > VIDEO_BPP4,
> > VIDEO_BPP8,
> > VIDEO_BPP16,
> > + VIDEO_BPP30,
> > VIDEO_BPP32,
> > };
>
> This breaks the enuam here. See the comment above:
>
> /*
> * Bits per pixel selector. Each value n is such that the bits-per-pixel is
> * 2 ^ n
> */
>
> Quite a few things rely on this, so there will need to be some
> changes. See for example VBNBYTE() immediately below.
Bleah. I suppose I need a separate field in struct video_priv to keep
track of the pixel format then.
> Also don't you need a CONFIG_VIDEO_BPP30 ?
The idea was that the code additions were minimal enough for that not
to make sense. But I'll need re-evaluate this after I figure out a
better way to distinguish between 8-bit and 10-bit color depth.
next prev parent reply other threads:[~2021-09-25 16:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 13:01 [PATCH 0/3] 30bpp framebuffer support Mark Kettenis
2021-09-16 13:01 ` [PATCH 1/3] video: Add 30bpp support Mark Kettenis
2021-09-25 13:40 ` Simon Glass
2021-09-25 16:55 ` Mark Kettenis [this message]
2021-09-16 13:01 ` [PATCH 2/3] efi_loader: GOP: " Mark Kettenis
2021-09-17 2:56 ` Heinrich Schuchardt
2021-09-17 9:23 ` Mark Kettenis
2021-09-17 11:29 ` Heinrich Schuchardt
2021-09-17 12:41 ` Mark Kettenis
2021-09-25 13:40 ` Simon Glass
2021-09-16 13:01 ` [PATCH 3/3] video: simplefb: " Mark Kettenis
2021-09-25 13:41 ` Simon Glass
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=5614855b50ef76ab@bloch.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=agraf@csgraf.de \
--cc=agust@denx.de \
--cc=kettenis@openbsd.org \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).