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

[Laurent Pinchart]

Hi Ville,

On Wednesday 27 March 2013 16:16:26 Ville Syrjälä wrote:
> On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote:
> > 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.

I agree with you. I was mostly interested to see if someone had any use case 
for this format. Unless one crops up I will then drop this patch.

Thank you for sharing your opinion.

-- 
Regards,

Laurent Pinchart