All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format
Date: Wed, 27 Mar 2013 16:16:26 +0200	[thread overview]
Message-ID: <20130327141626.GB4469@intel.com> (raw)
In-Reply-To: <13394928.VeZPoV0JSg@avalon>

On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote:
> Hi Ville,
> 
> On Wednesday 27 March 2013 13:06:20 Ville Syrjälä wrote:
> > On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote:
> > > This format is an odd beast, implemented by Renesas R-Car hardware. It
> > > stores RGB 6:6:6 pixels in 32 bits as
> > > 
> > > [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > <laurent.pinchart+renesas@ideasonboard.com>
> > > ---
> > > 
> > > Hello,
> > > 
> > > I came across this weird format on a Renesas SoC display controller. This
> > > is essentially XRGB8888 with the two low order bits of each component
> > > ignored by the hardware.
> > 
> > It sounds like it's no different than shoveling XRGB8888 down a 6bpc
> > pipe w/o dithering.
> > 
> > Could we just pretend it's XRGB8888, or can the low order bits have
> > some special meaning which would require treating them as special?
> 
> The hardware supports both XRGB8888 and the weird RGB 666 format, so I need a 
> new 4CC if I want to expose both to userspace.

I see.

> If the display uses a 6bpc pipe XRGB888 and RGB 666 should be identical. If 
> the display uses a 8bpc pipe then the two formats will be different. What 
> remains to be found is a use case where an application would fill the two low 
> order bits with a non-zero value and expect the hardware to ignore them.

Right. Unless the 6:6:6 format has some tangible benefit, like being
faster to render, or using the extra bits for some other information,
personally I'd lean towards not exposing it.

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2013-03-27 14:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-27  9:19 [RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format Laurent Pinchart
2013-03-27 11:06 ` Ville Syrjälä
2013-03-27 14:09   ` Laurent Pinchart
2013-03-27 14:16     ` Ville Syrjälä [this message]
2013-03-27 14:21       ` Laurent Pinchart

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=20130327141626.GB4469@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    /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.