Problem with gspca and zc3xx

Problem with gspca and zc3xx

[Jose Alberto Reguero]

When capturing with mplayer I have this erros and the bottom of the image is 
black.

[mjpeg @ 0xd2f300]error y=29 x=0                           
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc                                 
[mjpeg @ 0xd2f300]error y=29 x=0                           
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc                                 
[mjpeg @ 0xd2f300]error y=29 x=0                           
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc                                 
[mjpeg @ 0xd2f300]error y=29 x=0                           
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc                                 
[mjpeg @ 0xd2f300]error y=29 x=0                           
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc                                 
[mjpeg @ 0xd2f300]error y=29 x=0                           
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc                                 
.....................

dmesg:

gspca: main v2.8.0 registered                
gspca: probing 046d:08dd
zc3xx: Sensor MC501CB
gspca: video0 created
gspca: probing 046d:08dd
gspca: intf != 0
gspca: probing 046d:08dd
gspca: intf != 0
usbcore: registered new interface driver zc3xx
zc3xx: registered

Jose Alberto

Re: Problem with gspca and zc3xx

[Jean-Francois Moine]

On Sat, 9 Jan 2010 00:15:31 +0100
Jose Alberto Reguero <jareguero@telefonica.net> wrote:

> When capturing with mplayer I have this erros and the bottom of the
> image is black.
> 
> [mjpeg @ 0xd2f300]error y=29 x=0                           
> [mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
	[snip]
> 
> gspca: main v2.8.0 registered                
> gspca: probing 046d:08dd
> zc3xx: Sensor MC501CB
> gspca: video0 created
> gspca: probing 046d:08dd
> gspca: intf != 0
> gspca: probing 046d:08dd
> gspca: intf != 0
> usbcore: registered new interface driver zc3xx
> zc3xx: registered

Hello Jose Alberto,

May you send me a raw image done by my program svv? (look in my web page
below - run it by 'svv -rg' and send me the generated image.dat)

Regards

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: Problem with gspca and zc3xx

[Jose Alberto Reguero]

[-- Attachment #1: Type: Text/Plain, Size: 893 bytes --]

El Domingo, 10 de Enero de 2010, Jean-Francois Moine escribió:
> On Sat, 9 Jan 2010 00:15:31 +0100
> 
> Jose Alberto Reguero <jareguero@telefonica.net> wrote:
> > When capturing with mplayer I have this erros and the bottom of the
> > image is black.
> >
> > [mjpeg @ 0xd2f300]error y=29 x=0
> > [mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
> 
> 	[snip]
> 
> > gspca: main v2.8.0 registered
> > gspca: probing 046d:08dd
> > zc3xx: Sensor MC501CB
> > gspca: video0 created
> > gspca: probing 046d:08dd
> > gspca: intf != 0
> > gspca: probing 046d:08dd
> > gspca: intf != 0
> > usbcore: registered new interface driver zc3xx
> > zc3xx: registered
> 
> Hello Jose Alberto,
> 
> May you send me a raw image done by my program svv? (look in my web page
> below - run it by 'svv -rg' and send me the generated image.dat)
> 
> Regards
> 

Jose Alberto

[-- Attachment #2: image.dat --]
[-- Type: image/jpeg, Size: 20454 bytes --]

Re: Problem with gspca and zc3xx

[Hans de Goede]

Hi,

On 01/10/2010 09:37 AM, Jean-Francois Moine wrote:
> On Sat, 9 Jan 2010 00:15:31 +0100
> Jose Alberto Reguero<jareguero@telefonica.net>  wrote:
>
>> When capturing with mplayer I have this erros and the bottom of the
>> image is black.
>>
>> [mjpeg @ 0xd2f300]error y=29 x=0
>> [mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
> 	[snip]
>>
>> gspca: main v2.8.0 registered
>> gspca: probing 046d:08dd
>> zc3xx: Sensor MC501CB
>> gspca: video0 created
>> gspca: probing 046d:08dd
>> gspca: intf != 0
>> gspca: probing 046d:08dd
>> gspca: intf != 0
>> usbcore: registered new interface driver zc3xx
>> zc3xx: registered
>
> Hello Jose Alberto,
>
> May you send me a raw image done by my program svv? (look in my web page
> below - run it by 'svv -rg' and send me the generated image.dat)
>

JF,

This is the infamous zc3xx bottom of the image is missing in 320x240 problem,
with several sensors the register settings we took from the windows driver
will only give you 320x232 (iirc), we tried changing them to get 320x240,
but then the camera would not stream. Most likely some timing issue between
bridge and sensor.

I once had a patch fixing this by actually reporting the broken modes as
320x232, but that never got applied as it breaks app which are hardcoded
to ask for 320x240. libv4l has had the ability to extend the 320x232 image
to 320x240 for a while now (by adding a few black lines at the top + bottom),
fixing the hardcoded apps problem.

So I think such a patch can and should be applied now. This will get rid
of the jpeg decompression errors reported by libv4l and in case if yuv mode
the ugly green bar with some random noise in it at the bottom.

I'm afraid my patch is most likely lost, but I can create a new one if you want,
I have access to quite a few zc3xx camera's, and more over what resolution
they are actually streaming at can be deducted from the register settings
in the driver.

Regards,

Hans

Re: Problem with gspca and zc3xx

[Jean-Francois Moine]

On Mon, 11 Jan 2010 09:37:29 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> This is the infamous zc3xx bottom of the image is missing in 320x240
> problem, with several sensors the register settings we took from the
> windows driver will only give you 320x232 (iirc), we tried changing
> them to get 320x240, but then the camera would not stream. Most
> likely some timing issue between bridge and sensor.
> 
> I once had a patch fixing this by actually reporting the broken modes
> as 320x232, but that never got applied as it breaks app which are
> hardcoded to ask for 320x240. libv4l has had the ability to extend
> the 320x232 image to 320x240 for a while now (by adding a few black
> lines at the top + bottom), fixing the hardcoded apps problem.
> 
> So I think such a patch can and should be applied now. This will get
> rid of the jpeg decompression errors reported by libv4l and in case
> if yuv mode the ugly green bar with some random noise in it at the
> bottom.
> 
> I'm afraid my patch is most likely lost, but I can create a new one
> if you want, I have access to quite a few zc3xx camera's, and more
> over what resolution they are actually streaming at can be deducted
> from the register settings in the driver.

Hi Hans,

As you may see in Jose Alberto's message, the problem occurs with
640x480 and, yes, the image bottom is lacking, but also the right side.

I did not lose your patch, but I did not apply it because most of the
time, the webcams work in the best resolution (VGA) and the associated
problem has not found yet a good resolution...

Regards.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: Problem with gspca and zc3xx

[Jose Alberto Reguero]

[-- Attachment #1: Type: Text/Plain, Size: 1936 bytes --]

El Lunes, 11 de Enero de 2010, Jean-Francois Moine escribió:
> On Mon, 11 Jan 2010 09:37:29 +0100
> 
> Hans de Goede <hdegoede@redhat.com> wrote:
> > This is the infamous zc3xx bottom of the image is missing in 320x240
> > problem, with several sensors the register settings we took from the
> > windows driver will only give you 320x232 (iirc), we tried changing
> > them to get 320x240, but then the camera would not stream. Most
> > likely some timing issue between bridge and sensor.
> >
> > I once had a patch fixing this by actually reporting the broken modes
> > as 320x232, but that never got applied as it breaks app which are
> > hardcoded to ask for 320x240. libv4l has had the ability to extend
> > the 320x232 image to 320x240 for a while now (by adding a few black
> > lines at the top + bottom), fixing the hardcoded apps problem.
> >
> > So I think such a patch can and should be applied now. This will get
> > rid of the jpeg decompression errors reported by libv4l and in case
> > if yuv mode the ugly green bar with some random noise in it at the
> > bottom.
> >
> > I'm afraid my patch is most likely lost, but I can create a new one
> > if you want, I have access to quite a few zc3xx camera's, and more
> > over what resolution they are actually streaming at can be deducted
> > from the register settings in the driver.
> 
> Hi Hans,
> 
> As you may see in Jose Alberto's message, the problem occurs with
> 640x480 and, yes, the image bottom is lacking, but also the right side.
> 
> I did not lose your patch, but I did not apply it because most of the
> time, the webcams work in the best resolution (VGA) and the associated
> problem has not found yet a good resolution...
> 
> Regards.
> 

I take another image with 640x480 and the bad bottom lines are 8. The right 
side look right this time. The good sizes are:
320x240->320x232  
640x480->640x472

Jose Alberto

[-- Attachment #2: image2.dat --]
[-- Type: image/jpeg, Size: 14348 bytes --]

Re: Problem with gspca and zc3xx

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 6461 bytes --]

Hi All,

On 01/11/2010 10:55 AM, Jean-Francois Moine wrote:
> On Mon, 11 Jan 2010 09:37:29 +0100
> Hans de Goede<hdegoede@redhat.com>  wrote:
>
>> This is the infamous zc3xx bottom of the image is missing in 320x240
>> problem, with several sensors the register settings we took from the
>> windows driver will only give you 320x232 (iirc), we tried changing
>> them to get 320x240, but then the camera would not stream. Most
>> likely some timing issue between bridge and sensor.
>>
>> I once had a patch fixing this by actually reporting the broken modes
>> as 320x232, but that never got applied as it breaks app which are
>> hardcoded to ask for 320x240. libv4l has had the ability to extend
>> the 320x232 image to 320x240 for a while now (by adding a few black
>> lines at the top + bottom), fixing the hardcoded apps problem.
>>
>> So I think such a patch can and should be applied now. This will get
>> rid of the jpeg decompression errors reported by libv4l and in case
>> if yuv mode the ugly green bar with some random noise in it at the
>> bottom.
>>
>> I'm afraid my patch is most likely lost, but I can create a new one
>> if you want, I have access to quite a few zc3xx camera's, and more
>> over what resolution they are actually streaming at can be deducted
>> from the register settings in the driver.
>
> Hi Hans,
>
> As you may see in Jose Alberto's message, the problem occurs with
> 640x480 and, yes, the image bottom is lacking, but also the right side.
>

Hmm, the right side missing would indicate some timing issue between sensor
and bridge, but it seems this is an intermittent problem, as in Jose's
last message only the last 8 lines are missing.

As for this happening also at 640x480, I re-checked things and that is the
same problem, here is a table of the resolutions per sensor, derived
from the register settings in zc3xx.c, iow this are the resolutions we
are telling the bridge to send us!

adcm2700        640x472         320x232
cs2102          640x480         320x240
cs2102k         640x480         320x240
gc0305          640x480         320x240
hdcs2020xb      640x480         320x240
hv7131bxx       640x480         320x240
hv7131cxx       640x480         320x240
icm105axx       640x480         320x240
MC501CB         640x472         320x232
OV7620          640x472         320x232
ov7630c         640x480         320x240
pas202b         640x480         320x232
mi0360soc       640x480         320x240
pb0330          640x480         320x240
PO2030          640x480         320x240
tas5130CK       640x480         320x240
tas5130cxx      640x480         320x240
tas5130c_vf0250 640x480         320x240

> I did not lose your patch, but I did not apply it because most of the
> time, the webcams work in the best resolution (VGA) and the associated
> problem has not found yet a good resolution...

It turns out I was wrong, and the problem happens for 3 of the 4 affected
sensors at both VGA and QVGA. What we are currently doing is telling the
bridge to send us these resolutions, and then telling userspace it is
getting something different. This is just plain wrong, no but ..., it
is just *wrong*.

This makes for users getting an image out of the cam like Jose is getting
with the last 8 lines garbled. And when they start their webcam application
from a terminal the terminal fills with:
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffec
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffd9
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff

Which is because libv4l expects there to be more data then it actually
is getting, as we are *lying* to it.

I know ideally we would change the register settings to actually get
640x480 and 320x240, but that won't work when you do that the camera's
with the affected sensors won't stream at all, that is I've tried
fiddling with the register settings for a pas202b equipped cam
for hours to fix 320x240 and I got no where at all.

I've done a new version of my patch, which also fixes the affected cams
at 640x480, please apply this, as said I know this isn't ideal, but it
is better then what we currently have. If we ever find register settings
to make these cams work at normal resolutions, we can always revert this.

I've tested the attached patch with the following cams:
Philips SPC 200NC               0471:0325       zc3xx   PAS106
Logitech QuickCam IM/Connect    046d:08d9       zc3xx   HV7131R
Logitech QuickCam E2500         046d:089d       zc3xx   MC501CB
Creative WebCam NX Pro          041e:401e       zc3xx   HV7131B
No brand                        0ac8:307b       zc3xx   ADCM2700
Labtec notebook cam             046d:08aa       zc3xx   PAS202B
Creative WebCam Notebook        041e:401f       zc3xx   TAS5130C
Creative Live! Cam Video IM     041e:4053       zc3xx   TAS5130-VF250

And for the 3 affected models it fixes the garbled bottom of the
image and the libv4lconvert error messages (which people keep
submitting bugs about).

Jose,

Can you please test the attached patch, do:
install mercurial (on Fedora yum install mercurial)
hg clone http://linuxtv.org/hg/~jfrancois/gspca/
cd gscpa
patch -p1 < [path-to]/gspca_zc3xx-8lines-missing.patch
make menuconfig
[choose exit]
make
sudo make install
[reboot]

Thanks & Regards,

Hans

[-- Attachment #2: gspca_zc3xx-8lines-missing.patch --]
[-- Type: text/plain, Size: 3493 bytes --]

diff -r 70b1d636a39a linux/drivers/media/video/gspca/zc3xx.c
--- a/linux/drivers/media/video/gspca/zc3xx.c	Sun Jan 10 23:34:57 2010 +0100
+++ b/linux/drivers/media/video/gspca/zc3xx.c	Mon Jan 11 22:44:45 2010 +0100
@@ -194,6 +194,34 @@
 		.priv = 0},
 };
 
+/* VGA with last 8 lines missing */
+static const struct v4l2_pix_format broken_vga_mode[] = {
+	{320, 232, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+		.bytesperline = 320,
+		.sizeimage = 320 * 232 * 3 / 8 + 590,
+		.colorspace = V4L2_COLORSPACE_JPEG,
+		.priv = 1},
+	{640, 472, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+		.bytesperline = 640,
+		.sizeimage = 640 * 472 * 3 / 8 + 590,
+		.colorspace = V4L2_COLORSPACE_JPEG,
+		.priv = 0},
+};
+
+/* VGA with last 8 lines missing in 320x240 mode */
+static const struct v4l2_pix_format pas202b_vga_mode[] = {
+	{320, 232, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+		.bytesperline = 320,
+		.sizeimage = 320 * 232 * 3 / 8 + 590,
+		.colorspace = V4L2_COLORSPACE_JPEG,
+		.priv = 1},
+	{640, 480, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+		.bytesperline = 640,
+		.sizeimage = 640 * 480 * 3 / 8 + 590,
+		.colorspace = V4L2_COLORSPACE_JPEG,
+		.priv = 0},
+};
+
 static const struct v4l2_pix_format sif_mode[] = {
 	{176, 144, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
 		.bytesperline = 176,
@@ -6651,7 +6679,8 @@
 	struct sd *sd = (struct sd *) gspca_dev;
 	struct cam *cam;
 	int sensor;
-	int vga = 1;		/* 1: vga, 0: sif */
+	/* 0: sif, 1: vga, 2: 640x472, 320x232, 3: 640x480, 320x232 */
+	int vga = 1;
 	static const __u8 gamma[SENSOR_MAX] = {
 		4,	/* SENSOR_ADCM2700 0 */
 		4,	/* SENSOR_CS2102 1 */
@@ -6689,6 +6718,7 @@
 			switch (sd->sensor) {
 			case SENSOR_MC501CB:
 				PDEBUG(D_PROBE, "Sensor MC501CB");
+				vga = 2; /* last 8 lines missing */
 				break;
 			case SENSOR_TAS5130C_VF0250:
 				PDEBUG(D_PROBE, "Sensor Tas5130 (VF0250)");
@@ -6729,6 +6759,7 @@
 			PDEBUG(D_PROBE, "Find Sensor PAS202B");
 			sd->sensor = SENSOR_PAS202B;
 			sd->sharpness = 1;
+			vga = 3; /* broken 320x240 (can only do 320x232) */
 			break;
 		case 0x0f:
 			PDEBUG(D_PROBE, "Find Sensor PAS106");
@@ -6765,6 +6796,7 @@
 		case 0x16:
 			PDEBUG(D_PROBE, "Find Sensor ADCM2700");
 			sd->sensor = SENSOR_ADCM2700;
+			vga = 2; /* last 8 lines missing */
 			break;
 		case 0x29:
 			PDEBUG(D_PROBE, "Find Sensor GC0305");
@@ -6782,6 +6814,7 @@
 		case 0x7620:
 			PDEBUG(D_PROBE, "Find Sensor OV7620");
 			sd->sensor = SENSOR_OV7620;
+			vga = 2; /* last 8 lines missing */
 			break;
 		case 0x7631:
 			PDEBUG(D_PROBE, "Find Sensor OV7630C");
@@ -6790,6 +6823,7 @@
 		case 0x7648:
 			PDEBUG(D_PROBE, "Find Sensor OV7648");
 			sd->sensor = SENSOR_OV7620;	/* same sensor (?) */
+			vga = 2; /* last 8 lines missing */
 			break;
 		default:
 			PDEBUG(D_ERR|D_PROBE, "Unknown sensor %04x", sensor);
@@ -6807,12 +6841,23 @@
 	cam = &gspca_dev->cam;
 /*fixme:test*/
 	gspca_dev->nbalt--;
-	if (vga) {
+	switch (vga) {
+	case 0:
+		cam->cam_mode = sif_mode;
+		cam->nmodes = ARRAY_SIZE(sif_mode);
+		break;
+	case 1:
 		cam->cam_mode = vga_mode;
 		cam->nmodes = ARRAY_SIZE(vga_mode);
-	} else {
-		cam->cam_mode = sif_mode;
-		cam->nmodes = ARRAY_SIZE(sif_mode);
+		break;
+	case 2:
+		cam->cam_mode = broken_vga_mode;
+		cam->nmodes = ARRAY_SIZE(broken_vga_mode);
+		break;
+	case 3:
+		cam->cam_mode = pas202b_vga_mode;
+		cam->nmodes = ARRAY_SIZE(pas202b_vga_mode);
+		break;
 	}
 	sd->brightness = sd_ctrls[SD_BRIGHTNESS].qctrl.default_value;
 	sd->contrast = sd_ctrls[SD_CONTRAST].qctrl.default_value;

Re: Problem with gspca and zc3xx

[Jean-Francois Moine]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

On Mon, 11 Jan 2010 15:49:55 +0100
Jose Alberto Reguero <jareguero@telefonica.net> wrote:

> I take another image with 640x480 and the bad bottom lines are 8. The
> right side look right this time. The good sizes are:
> 320x240->320x232  
> 640x480->640x472

Hi Jose Alberto and Hans,

Hans, I modified a bit your patch to handle the 2 resolutions (also, the
problem with pas202b does not exist anymore). May you sign or ack it?

Jose Alberto, the attached patch is to be applied to the last version
of the gspca in my test repository at LinuxTv.org
	http://linuxtv.org/hg/~jfrancois/gspca
May you try it?

Regards.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[-- Attachment #2: zc3xx.pat --]
[-- Type: application/octet-stream, Size: 2571 bytes --]

diff -r 1496806932f0 linux/drivers/media/video/gspca/zc3xx.c
--- a/linux/drivers/media/video/gspca/zc3xx.c	Mon Jan 11 19:06:12 2010 +0100
+++ b/linux/drivers/media/video/gspca/zc3xx.c	Tue Jan 12 09:29:21 2010 +0100
@@ -192,6 +192,19 @@
 		.priv = 0},
 };
 
+static const struct v4l2_pix_format broken_vga_mode[] = {
+	{320, 232, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+		.bytesperline = 320,
+		.sizeimage = 320 * 232 * 4 / 8 + 590,
+		.colorspace = V4L2_COLORSPACE_JPEG,
+		.priv = 1},
+	{640, 472, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+		.bytesperline = 640,
+		.sizeimage = 640 * 472 * 3 / 8 + 590,
+		.colorspace = V4L2_COLORSPACE_JPEG,
+		.priv = 0},
+};
+
 static const struct v4l2_pix_format sif_mode[] = {
 	{176, 144, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
 		.bytesperline = 176,
@@ -6606,7 +6619,6 @@
 	struct sd *sd = (struct sd *) gspca_dev;
 	struct cam *cam;
 	int sensor;
-	int vga = 1;		/* 1: vga, 0: sif */
 	static const u8 gamma[SENSOR_MAX] = {
 		4,	/* SENSOR_ADCM2700 0 */
 		4,	/* SENSOR_CS2102 1 */
@@ -6628,6 +6640,27 @@
 		3,	/* SENSOR_TAS5130CXX 17 */
 		3,	/* SENSOR_TAS5130C_VF0250 18 */
 	};
+	static const u8 mode_tb[SENSOR_MAX] = {
+		2,	/* SENSOR_ADCM2700 0 */
+		1,	/* SENSOR_CS2102 1 */
+		1,	/* SENSOR_CS2102K 2 */
+		1,	/* SENSOR_GC0305 3 */
+		1,	/* SENSOR_HDCS2020b 4 */
+		1,	/* SENSOR_HV7131B 5 */
+		1,	/* SENSOR_HV7131C 6 */
+		1,	/* SENSOR_ICM105A 7 */
+		2,	/* SENSOR_MC501CB 8 */
+		1,	/* SENSOR_MI0360SOC 9 */
+		2,	/* SENSOR_OV7620 10 */
+		1,	/* SENSOR_OV7630C 11 */
+		0,	/* SENSOR_PAS106 12 */
+		1,	/* SENSOR_PAS202B 13 */
+		1,	/* SENSOR_PB0330 14 */
+		1,	/* SENSOR_PO2030 15 */
+		1,	/* SENSOR_TAS5130CK 16 */
+		1,	/* SENSOR_TAS5130CXX 17 */
+		1,	/* SENSOR_TAS5130C_VF0250 18 */
+	};
 
 	/* define some sensors from the vendor/product */
 	sd->sharpness = SHARPNESS_DEF;
@@ -6701,7 +6734,6 @@
 		case 0x0f:
 			PDEBUG(D_PROBE, "Find Sensor PAS106");
 			sd->sensor = SENSOR_PAS106;
-			vga = 0;		/* SIF */
 			break;
 		case 0x10:
 		case 0x12:
@@ -6777,12 +6809,20 @@
 	cam = &gspca_dev->cam;
 /*fixme:test*/
 	gspca_dev->nbalt--;
-	if (vga) {
+	switch (mode_tb[sd->sensor]) {
+	case 0:
+		cam->cam_mode = sif_mode;
+		cam->nmodes = ARRAY_SIZE(sif_mode);
+		break;
+	case 1:
 		cam->cam_mode = vga_mode;
 		cam->nmodes = ARRAY_SIZE(vga_mode);
-	} else {
-		cam->cam_mode = sif_mode;
-		cam->nmodes = ARRAY_SIZE(sif_mode);
+		break;
+	default:
+/*	case 2: */
+		cam->cam_mode = broken_vga_mode;
+		cam->nmodes = ARRAY_SIZE(broken_vga_mode);
+		break;
 	}
 	sd->brightness = BRIGHTNESS_DEF;
 	sd->contrast = CONTRAST_DEF;

Re: Problem with gspca and zc3xx

[Hans de Goede]

Hi,

On 01/12/2010 09:36 AM, Jean-Francois Moine wrote:
> On Mon, 11 Jan 2010 15:49:55 +0100
> Jose Alberto Reguero<jareguero@telefonica.net>  wrote:
>
>> I take another image with 640x480 and the bad bottom lines are 8. The
>> right side look right this time. The good sizes are:
>> 320x240->320x232
>> 640x480->640x472
>
> Hi Jose Alberto and Hans,
>
> Hans, I modified a bit your patch to handle the 2 resolutions (also, the
> problem with pas202b does not exist anymore). May you sign or ack it?
>

Thanks!

It seems our mails crossed each other, you are right the pas202b
320x240 issue (the pas202b is a cam I have, and it only had the
issue at 320x240, hence the incompleteness of my patch) is fixed
in your tree, excellent!

The patch is:
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans

Re: Problem with gspca and zc3xx

[Jose Alberto Reguero]

El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió:
> On Mon, 11 Jan 2010 15:49:55 +0100
> 
> Jose Alberto Reguero <jareguero@telefonica.net> wrote:
> > I take another image with 640x480 and the bad bottom lines are 8. The
> > right side look right this time. The good sizes are:
> > 320x240->320x232
> > 640x480->640x472
> 
> Hi Jose Alberto and Hans,
> 
> Hans, I modified a bit your patch to handle the 2 resolutions (also, the
> problem with pas202b does not exist anymore). May you sign or ack it?
> 
> Jose Alberto, the attached patch is to be applied to the last version
> of the gspca in my test repository at LinuxTv.org
> 	http://linuxtv.org/hg/~jfrancois/gspca
> May you try it?
> 
> Regards.
> 

 The patch works well.
There is another problem. When autogain is on(default), the image is bad. It 
is possible to put autogain off by default?

Thanks.
Jose Alberto

Re: Problem with gspca and zc3xx

[Jose Alberto Reguero]

El Martes, 12 de Enero de 2010, Jose Alberto Reguero escribió:
> El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió:
> > On Mon, 11 Jan 2010 15:49:55 +0100
> >
> > Jose Alberto Reguero <jareguero@telefonica.net> wrote:
> > > I take another image with 640x480 and the bad bottom lines are 8. The
> > > right side look right this time. The good sizes are:
> > > 320x240->320x232
> > > 640x480->640x472
> >
> > Hi Jose Alberto and Hans,
> >
> > Hans, I modified a bit your patch to handle the 2 resolutions (also, the
> > problem with pas202b does not exist anymore). May you sign or ack it?
> >
> > Jose Alberto, the attached patch is to be applied to the last version
> > of the gspca in my test repository at LinuxTv.org
> > 	http://linuxtv.org/hg/~jfrancois/gspca
> > May you try it?
> >
> > Regards.
> 
>  The patch works well.
> There is another problem. When autogain is on(default), the image is bad.
>  It is possible to put autogain off by default?
> 
> Thanks.
> Jose Alberto

Autogain works well again. I can't reproduce the problem. Perhaps the debug 
messages. (Now I have debug off).

Thanks.
Jose Alberto

Re: Problem with gspca and zc3xx

[Jose Alberto Reguero]

[-- Attachment #1: Type: Text/Plain, Size: 1570 bytes --]

El Miércoles, 13 de Enero de 2010, Jose Alberto Reguero escribió:
> El Martes, 12 de Enero de 2010, Jose Alberto Reguero escribió:
> > El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió:
> > > On Mon, 11 Jan 2010 15:49:55 +0100
> > >
> > > Jose Alberto Reguero <jareguero@telefonica.net> wrote:
> > > > I take another image with 640x480 and the bad bottom lines are 8. The
> > > > right side look right this time. The good sizes are:
> > > > 320x240->320x232
> > > > 640x480->640x472
> > >
> > > Hi Jose Alberto and Hans,
> > >
> > > Hans, I modified a bit your patch to handle the 2 resolutions (also,
> > > the problem with pas202b does not exist anymore). May you sign or ack
> > > it?
> > >
> > > Jose Alberto, the attached patch is to be applied to the last version
> > > of the gspca in my test repository at LinuxTv.org
> > > 	http://linuxtv.org/hg/~jfrancois/gspca
> > > May you try it?
> > >
> > > Regards.
> >
> >  The patch works well.
> > There is another problem. When autogain is on(default), the image is bad.
> >  It is possible to put autogain off by default?
> >
> > Thanks.
> > Jose Alberto
> 
> Autogain works well again. I can't reproduce the problem. Perhaps the debug
> messages. (Now I have debug off).
> 
> Thanks.
> Jose Alberto

I found the problem. Autogain don't work well if brightness is de default 
value(128). if brightness is less(64) autogain work well. There is a problem 
when setting the brightness. It is safe to remove the brightness control?
Patch attached.

Jose Alberto

[-- Attachment #2: zc3xx.patch --]
[-- Type: text/x-patch, Size: 607 bytes --]

diff -r d490d84a64ac linux/drivers/media/video/gspca/zc3xx.c
--- a/linux/drivers/media/video/gspca/zc3xx.c	Wed Jan 13 12:11:34 2010 -0200
+++ b/linux/drivers/media/video/gspca/zc3xx.c	Thu Jan 14 17:03:10 2010 +0100
@@ -6028,6 +6041,7 @@
 	case SENSOR_OV7620:
 	case SENSOR_PAS202B:
 	case SENSOR_PO2030:
+	case SENSOR_MC501CB:
 		return;
 	}
 /*fixme: is it really write to 011d and 018d for all other sensors? */
@@ -6796,6 +6837,7 @@
 	case SENSOR_OV7620:
 	case SENSOR_PAS202B:
 	case SENSOR_PO2030:
+	case SENSOR_MC501CB:
 		gspca_dev->ctrl_dis = (1 << BRIGHTNESS_IDX);
 		break;
 	case SENSOR_HV7131B:

Re: Problem with gspca and zc3xx

[Fabio Rossi]

On Tue, 12 Jan 2010 00:35:28 -0800 Jean-Francois Moine wrote:

> Hi Jose Alberto and Hans,
> 
> Hans, I modified a bit your patch to handle the 2 resolutions (also, the
> problem with pas202b does not exist anymore). May you sign or ack it?
> 
> Jose Alberto, the attached patch is to be applied to the last version
> of the gspca in my test repository at LinuxTv.org
>         http://linuxtv.org/hg/~jfrancois/gspca
> May you try it?
> 
> Regards.

Hi  Jean-Francois,
I applied your patch and it works, the 8 black lines at the bottom are 
disappeared.

Without the patch I was getting tons of 

 libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff

error messages while now I get only once as soon as I launch svv. I'm 
wondering what is causing now this minor problem.

Thanks,
Fabio

Re: Problem with gspca and zc3xx

[Mauro Carvalho Chehab]

Jose Alberto Reguero wrote:
> El Miércoles, 13 de Enero de 2010, Jose Alberto Reguero escribió:
>> El Martes, 12 de Enero de 2010, Jose Alberto Reguero escribió:
>>> El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió:
>>>> On Mon, 11 Jan 2010 15:49:55 +0100
>>>>
>>>> Jose Alberto Reguero <jareguero@telefonica.net> wrote:
>>>>> I take another image with 640x480 and the bad bottom lines are 8. The
>>>>> right side look right this time. The good sizes are:
>>>>> 320x240->320x232
>>>>> 640x480->640x472
>>>> Hi Jose Alberto and Hans,
>>>>
>>>> Hans, I modified a bit your patch to handle the 2 resolutions (also,
>>>> the problem with pas202b does not exist anymore). May you sign or ack
>>>> it?
>>>>
>>>> Jose Alberto, the attached patch is to be applied to the last version
>>>> of the gspca in my test repository at LinuxTv.org
>>>> 	http://linuxtv.org/hg/~jfrancois/gspca
>>>> May you try it?
>>>>
>>>> Regards.
>>>  The patch works well.
>>> There is another problem. When autogain is on(default), the image is bad.
>>>  It is possible to put autogain off by default?
>>>
>>> Thanks.
>>> Jose Alberto
>> Autogain works well again. I can't reproduce the problem. Perhaps the debug
>> messages. (Now I have debug off).
>>
>> Thanks.
>> Jose Alberto
> 
> I found the problem. Autogain don't work well if brightness is de default 
> value(128). if brightness is less(64) autogain work well. There is a problem 
> when setting the brightness. It is safe to remove the brightness control?
> Patch attached.
> 
> Jose Alberto

This patch doesn't apply anymore. I'm not sure if the issue were fixed upstream. If
not, please re-base your patch against my git tree and send it again.

patching file drivers/media/video/gspca/zc3xx.c
Hunk #1 succeeded at 6086 with fuzz 1 (offset 45 lines).
Hunk #2 FAILED at 6882.
1 out of 2 hunks FAILED -- saving rejects to file drivers/media/video/gspca/zc3xx.c.rej
>>> Patch patches/lmml_72895_problem_with_gspca_and_zc3xx.patch doesn't apply

-- 

Cheers,
Mauro

Re: Problem with gspca and zc3xx

[Jean-Francois Moine]

On Thu, 06 May 2010 15:09:33 -0300
Mauro Carvalho Chehab <mchehab@redhat.com> wrote:

> > I found the problem. Autogain don't work well if brightness is de
> > default value(128). if brightness is less(64) autogain work well.
> > There is a problem when setting the brightness. It is safe to
> > remove the brightness control? Patch attached.
> > 
> > Jose Alberto  
> 
> This patch doesn't apply anymore. I'm not sure if the issue were
> fixed upstream. If not, please re-base your patch against my git tree
> and send it again.
> 
> patching file drivers/media/video/gspca/zc3xx.c
> Hunk #1 succeeded at 6086 with fuzz 1 (offset 45 lines).
> Hunk #2 FAILED at 6882.
> 1 out of 2 hunks FAILED -- saving rejects to file
> drivers/media/video/gspca/zc3xx.c.rej
> >>> Patch patches/lmml_72895_problem_with_gspca_and_zc3xx.patch
> >>> doesn't apply

Jose's patch is not needed anymore. I completely removed the brightness
control as it was done: it did not work for any zc3xx webcam. The git
change is bdd13e1bf3ada06bb9ccd04f5f65f7912eff72af.

Cheers.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/