[RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

[Ville Syrjälä]

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