[cpia] Re: new cpia driver and camstream (fwd)

[Johannes Erdfelt]

Just when you thought you were safe.

BTW - I submitted a 2.3 patch, Alan took it and submitted it to Linus.

JE

----- Forwarded message from Alan Cox <alan@lxorguk.ukuu.org.uk> -----

Subject: Re: new cpia driver and camstream
To: nemosoft@smcc.demon.nl (Nemosoft Unv.)
Date: Sat, 25 Mar 2000 14:15:05 +0000 (GMT)
Cc: randy.dunlap@intel.com (Dunlap Randy),
        jerdfelt@valinux.com (Johannes Erdfelt),
        alan@lxorguk.ukuu.org.uk (Alan Cox),
        linux-usb@suse.com (linux-usb@suse.com)
X-Mailer: ELM [version 2.5 PL1]
From: Alan Cox <alan@lxorguk.ukuu.org.uk>

> 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).

The read case is broken.

> c-qcam             |  RGB (5)|   -     |   -     |   -     |

This one is wrong. As is the pms.

> "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.

Its actually basically endianness accident I think. 

> 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).

An invalid format request should error I guess. We never quite decided if it
should error or offer you the next nearest. Error probably.

We should stick with BGR. This hasnt really come up before because TV
overlay doesn't care and hardcore capture and process freaks all use YUVspace

Alan



----- End forwarded message -----