gspca-sonixb and sn9c102 produce incompatible V4L2_PIX_FMT_SN9C10X

DISCUSSION Hans de Goede 3 participants 4 messages Aug 29, 2008 – Sep 1, 2008 Media (V4L/DVB)

Share & tools

Hans de Goede

author

2008-08-29 10:27 UTC #0 lore raw

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

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.

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hans Verkuil

2008-08-29 11:05 UTC #1 lore raw

Quoted 32 lines · 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:

Quoted 8 lines

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.

Quoted 3 lines

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

Quoted 3 lines

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

JoJo jojo

2008-09-01 19:19 UTC #2 lore raw

In reply to Hans de Goede

Quoted 10 lines · Hans de Goede

Hi all,
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).

What are the other 4 USB ids of sensors that you can't test yourself? Maybe we can help.

-JoJo

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hans de Goede

author

2008-09-01 20:57 UTC #3 lore raw

Quoted 13 lines · JoJo jojo

Quoted 10 lines · Hans de Goede
Hi all,
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).

Quoted 3 lines

What are the other 4 USB ids of sensors that you can't test yourself? Maybe we can help.

We could use testing for the following usb-id's:

        {USB_DEVICE(0x0c45, 0x6007), SB(TAS5110, 101)}, /* TAS5110D */
        {USB_DEVICE(0x0c45, 0x6009), SB(PAS106, 101)},
        {USB_DEVICE(0x0c45, 0x600d), SB(PAS106, 101)},
        {USB_DEVICE(0x0c45, 0x6019), SB(OV7630, 101)},
        {USB_DEVICE(0x0c45, 0x6024), SB(TAS5130CXX, 102)},
        {USB_DEVICE(0x0c45, 0x6025), SB(TAS5130CXX, 102)},
        {USB_DEVICE(0x0c45, 0x6028), SB(PAS202, 102)},
        {USB_DEVICE(0x0c45, 0x6029), SB(PAS106, 102)},
        {USB_DEVICE(0x0c45, 0x602c), SB(OV7630, 102)},
        {USB_DEVICE(0x0c45, 0x602d), SB(HV7131R, 102)},
        {USB_DEVICE(0x0c45, 0x602e), SB(OV7630, 102)},
        {USB_DEVICE(0x0c45, 0x60af), SB(PAS202, 103)},

Which should currently be supported, we are also interested in any cams with a usb-id matching: 0c45:60?? or 0c45:61??, some may just need to right entry added to the usb-id table, while others may require adding some code.

Thanks & Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list