Re: Problem with gspca and zc3xx
On Thu, 06 May 2010 15:09:33 -0300 Mauro Carvalho Chehab 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with gspca and zc3xx
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with gspca and zc3xx
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: 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with gspca and zc3xx
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 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 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
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with gspca and zc3xx
El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió: > On Mon, 11 Jan 2010 15:49:55 +0100 > > Jose Alberto Reguero 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with gspca and zc3xx
Hi, On 01/12/2010 09:36 AM, Jean-Francois Moine wrote: On Mon, 11 Jan 2010 15:49:55 +0100 Jose Alberto Reguero 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 Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with gspca and zc3xx
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 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! adcm2700640x472 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: libv4lconvert: Error decompressing JPEG: unknown huffman code: ffec libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: ffd9 libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: 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 hou
Re: Problem with gspca and zc3xx
On Mon, 11 Jan 2010 15:49:55 +0100 Jose Alberto Reguero 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/ zc3xx.pat Description: Binary data
Re: Problem with gspca and zc3xx
El Lunes, 11 de Enero de 2010, Jean-Francois Moine escribió: > On Mon, 11 Jan 2010 09:37:29 +0100 > > Hans de Goede 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 <>
Re: Problem with gspca and zc3xx
On Mon, 11 Jan 2010 09:37:29 +0100 Hans de Goede 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with gspca and zc3xx
Hi, On 01/10/2010 09:37 AM, Jean-Francois Moine wrote: On Sat, 9 Jan 2010 00:15:31 +0100 Jose Alberto Reguero 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with gspca and zc3xx
El Domingo, 10 de Enero de 2010, Jean-Francois Moine escribió: > On Sat, 9 Jan 2010 00:15:31 +0100 > > Jose Alberto Reguero 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 <>
Re: Problem with gspca and zc3xx
On Sat, 9 Jan 2010 00:15:31 +0100 Jose Alberto Reguero 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem with gspca and zc3xx
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
