v4l-utils: libv4l1: When asked for RGB, return RGB and not BGR

libv4l1: When asked for RGB, return RGB and not BGR

Signed-off-by Marc Deslauriers<[email protected]>

---
  lib/libv4l1/libv4l1.c |    8 ++++----
  1 files changed, 4 insertions(+), 4 deletions(-)

lib/libv4l1/libv4l1.c +2 -2

index cb53899..202f020 100644
@@ -87,9 +87,9 @@ static unsigned int palette_to_pixelformat(unsigned
 int palette)
  	case VIDEO_PALETTE_RGB565:
  		return V4L2_PIX_FMT_RGB565;
  	case VIDEO_PALETTE_RGB24:
-		return V4L2_PIX_FMT_BGR24;
+		return V4L2_PIX_FMT_RGB24;
  	case VIDEO_PALETTE_RGB32:
-		return V4L2_PIX_FMT_BGR32;
+		return V4L2_PIX_FMT_RGB32;
  	case VIDEO_PALETTE_YUYV:
  		return V4L2_PIX_FMT_YUYV;

case VIDEO_PALETTE_YUV422:

lib/libv4l1/libv4l1.c +2 -2

@@ -118,9 +118,9 @@ static unsigned int pixelformat_to_palette(unsigned
 int pixelformat)
  		return VIDEO_PALETTE_RGB555;
  	case V4L2_PIX_FMT_RGB565:
  		return VIDEO_PALETTE_RGB565;
-	case V4L2_PIX_FMT_BGR24:
+	case V4L2_PIX_FMT_RGB24:
  		return VIDEO_PALETTE_RGB24;
-	case V4L2_PIX_FMT_BGR32:
+	case V4L2_PIX_FMT_RGB32:
  		return VIDEO_PALETTE_RGB32;
  	case V4L2_PIX_FMT_YUYV:

return VIDEO_PALETTE_YUYV;

Hi,

NACK

The byte ordering in v4l1's VIDEO_PALETTE_RGB24 was never really clear, but the kernel v4l1 compatibility ioctl handling has been mapping VIDEO_PALETTE_RGB24 <-> V4L2_PIX_FMT_BGR24 for ever and many v4l1 apps actually expect VIDEO_PALETTE_RGB24 to be BGR24. The only one I know of to get this wrong is camorama and the solution there is to:
1) not use camorama
2) if you use camorama anyway, fix it, there is a list of patches fixing various issues available here:
http://pkgs.fedoraproject.org/gitweb/?p=camorama.git;a=tree

Regards,