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@xxxxxxxxxxxxxxxx> > > --- > > > > 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. 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. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
