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,
Hans
On 10/18/2010 02:44 PM, Marc Deslauriers wrote:
libv4l1: When asked for RGB, return RGB and not BGR
Signed-off-by: Marc Deslauriers<marc.deslauri...@ubuntu.com>
---
lib/libv4l1/libv4l1.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index cb53899..202f020 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -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:
@@ -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;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
