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.