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
