Well, the CPiA driver goes by what Peter Pregler found out on the V4L
list. And actually, Peter (I think) rewrote that portion of my code to
be more flexible as well as support some different formats.
At this point, I could care less which way it's supposed to be since the
code is there for both ways and it's a couple of lines change to switch
it, but until someone more definitive (eg Alan or Linus) says something
different than Peter, I won't dare touching it.
Of course, we could sidestep this problem by returning only YUV to
userspace :) Ok, ok, wait till 2.5
JE
On Fri, Mar 24, 2000, Dunlap, Randy <[EMAIL PROTECTED]> wrote:
> Hi Nemosoft,
>
> Thanks for all your digging. I didn't realize
> it was going to be such an endeavor.
>
> I thought I was looking at a blue alien..
>
> I think that Johannes will be reversing one of the
> cpia return formats. But you're right, it is a mess.
>
> ~Randy
>
>
> -----Original Message-----
> From: Nemosoft Unv. [mailto:[EMAIL PROTECTED]]
>
> Hi,
>
> On 25-Mar-00 Dunlap, Randy wrote:
> > Hi Nemosoft,
> >
> > I'm using the new cpia driver (works with parallel
> > port or USB cpia cameras) with camstream.
> > It's scary. I have blue skin again.
>
> No, it's a sign you have just been smurfed :-)
>
> > This is obviously the RGB vs. BGR problem.
> > Where's the correct solution to this problem?
> > (where should it be?)
>
> Argh! This 'new' CPiA code tries to outsmart us... It's quite incompatible
> with the other webcam drivers (ibmcam and ov511) at the moment!
>
> What's the case? The new CPiA driver takes into account whether the image is
> being requested through read() or mmap(). With read() it now returns a RGB
> palette, and with mmap() BGR. However, the ibmcam, ov511 and my Philips
> drivers always return BGR (my drivers don't have mmap() yet, but that shall
> use BGR too).
>
> I've been told this by Peter Pregler:
>
> >> I discussed this on the v4l list. The 'correct' way is:
> >> - for read: rgb is just rgb
> >> - for mmap: rgb24/32 is actually bgr24/32, rgb15/16 is rgb
>
> >> There is no reasoning for the above except history and misunderstanding
>
> Now this of course just completely insane... More so since NONE OF THE
> DRIVERS out there do this right.
>
> After some 2 hours of reading code and downloading PDFs, here's a small
> table
> of all V4L devices in 2.3.51, and which format they use for which palette:
>
> | read() | mmap() |
> | RGB24 | RGB32 | RGB24 | RGB32 |
> -------------------+---------+---------+---------+---------+
> Zoran 36057/36060 | - | - | BGR | BGRa |
> Zoran 36120/36125 | BGR | (1) | BGR | BGRa |
> bttv (bt848 et all)| BGR (2)| BGRa | BGR | BGRa |
> Stradis (3) | - | - | - | - |
> bw-qcam | (4) | (4) | - | - |
> c-qcam | RGB (5)| - | - | - |
>
> usb/old-cpia | BGR | - | BGR | - |
> usb/new-cpia | RGB | RGBa | BGR | BGRa |
> usb/ibmcam | BGR | - | BGR | - |
> usb/ov511 | BGR | - | BGR | - |
> usb/philips (6) | BGR | RGBa | (BGR) | (RGBa) |
>
> (1) The read() function always uses PALETTE_RGB24, thus BGR format.
> (2) The code says this function is broken;
> (3) This seems to be a write-only device (?)
> (4) Only has GREY palette, so no colour problems
> (5) Not sure if this is RGB, since code doesn't mention it
> (6) RGBa is used to quickly fill imagebuffers in Qt (okay, this is a hack)
>
> So you see... this is just a big mess. None of the devices adher to this
> "standard", which is mainly "broken" because the grabber cards seem to
> prefer
> BGR format (fortunately, they all use the same format!). And some drivers
> changed from RGB to BGR at some point in their development.
>
> To make things worse, some of the V4L utilities don't pay attention to
> VIDEO_PALETTE at all, and blindly assume one format or the other, let alone
> set a palette...
>
> My suggestion is to stick to BGR format, ditch RGB, and try to get "illegal"
> formats out (like the Zoran 36120 which always returns BGR format with read,
> even if you had set VIDEO_PALETTE_RGB32).
>
> - Nemosoft
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
