Re: [v4l-dvb-maintainer] gspca-sonixb and sn9c102 produce incompatible V4L2_PIX_FMT_SN9C10X

[Hans Verkuil <hverkuil@xxxxxxxxx>]

On Friday 29 August 2008 12:38:16 Hans de Goede wrote:
> Hi all,
>
> I've been working on adding support for raw bayer output to
> gspca-sonixb, so that it has feature parity on this point with
> sonixb, and we can move tested cams over (as gspca-sonixb has other
> features which sonixb lacks) without regressions.
>
> While doing this I noticed that if I disable the compression in the
> bridge gspca produces raw GBRG bayer data, just like the compressed
> data is GBRG after decompression, but the sn9c102 driver produces raw
> BGGR data. Some further investigation has found that this is caused
> by a small difference in the way the 2 drivers program register 0x12
> (hstart) of the bridge. In gspca there are several init tables (one
> per sensor) with things like this:
>
>          0x00, 0x01, 0x00, 0x46, 0x09, 0x0a,     /* shift from 0x45
> 0x09 0x0a */
>
> Notice the comment that the 0x46 used to be 0x45 this is the value
> for the hstart register, and the sn9c102 driver has the 0x45 value
> here. This starting one pixel later (then both sn9c102 and windows)
> of the gspca sonixb driver causes the change from BGGR to GBRG bayer.
> The problem here is that the bayer in the compressed data after
> decompressoon also changes. So the data produced as
> V4L2_PIX_FMT_SN9C10X is different between the gspca-sonixb driver and
> the sn9c102 driver, also libv4l currently only works correctly with
> the gspca driver. Whereas existing applications which directly
> understand V4L2_PIX_FMT_SN9C10X such as sonic-snap only work correct
> with the sn9c102 driver.
>
> I see 2 possible solutions:
>
> 1) Fix the gspca driver and libv4l to produce / expect BGGR bayer
> inside the V4L2_PIX_FMT_SN9C10X data, making gspca compatible with
> the already released in an official kernel sn9c102 driver. The
> downside of this is that we loose all the testing done with gspca
> (both v1 and v2) with the current gspca settings but given that
> windows uses the sn9c102 settings I don't expect much of a problem
> from this (and I can test the new settings for 3 of the 7 supported
> sensors).

Sounds good.

> 2) Add a new V4L2_PIX_FMT_SN9C10X_GBRG format for the gspca driver,
> although this avoids making changes with possible regressions to
> gspca, its too ugly for words IMHO.

Sounds not so good :-)

> I'll be writing a patch against gspca and submitting it for this
> soon, but first I wanted to give you all a headsup and give you
> chance to tell me how bad my idea how to solve this is.

Regards,

	Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list