My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Xavion]

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

My Microdia (SN9C201) webcam was working in Linux, but it has been
failing lately.  Take a look at the attached snapshot to see what I
mean.  It's like that all the time in Linux these days, but it works
perfectly in Windows.

I've tried using different USB ports and even a different computer
without success.  Does anyone know what's going on here and how we can
prevent this problem?  Let me know if you want me to send any
additional information.


`--> lsusb | grep Cam
Bus 001 Device 006: ID 0c45:627b Microdia PC Camera (SN9C201 + OV7660)


`--> lsmod | grep sn9c
gspca_sn9c20x          27437  1
gspca_main             21628  2 gspca_sn9c20x
usbcore               146241  11
ehci_hcd,uhci_hcd,usbhid,snd_usbmidi_lib,snd_usb_audio,uas,gspca_main,usb_storage,gspca_sn9c20x,ums_cypress


`--> uname -a
Linux <Host> 3.2.8-1-ARCH #1 SMP PREEMPT Mon Feb 27 21:51:46 CET 2012
x86_64 Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel
GNU/Linux


`--> tail /var/log/kernel.log
...
Mar  3 09:54:10 <Host> kernel: [ 4122.732350] gspca_sn9c20x: Set 640x480
Mar  3 09:56:28 <Host> kernel: [ 4260.776109] gspca_sn9c20x: Set 640x480
Mar  3 09:56:29 <Host> kernel: [ 4261.408847] gspca_main: ISOC data
error: [0] len=0, status=-18
Mar  3 09:56:29 <Host> kernel: [ 4261.408853] gspca_main: ISOC data
error: [1] len=0, status=-18
Mar  3 10:21:41 <Host> kernel: [ 5773.917404] gspca_sn9c20x: Set 640x480


`--> tail /var/log/errors.log
Mar  3 10:48:00 <Host> motion: [1] Retrying until successful
connection with camera
Mar  3 10:48:03 <Host> motion: [1] v4l2_next: VIDIOC_DQBUF: EIO
(s->pframe 0): Input/output error
Mar  3 10:48:03 <Host> motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument
Mar  3 10:48:03 <Host> motion: [1] Video device fatal error - Closing
video device
Mar  3 10:48:10 <Host> motion: [1] Retrying until successful
connection with camera
...

[-- Attachment #2: 2012-03-02-205300.jpg --]
[-- Type: image/jpeg, Size: 66735 bytes --]

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Hans de Goede]

Hi,

On 03/03/2012 01:23 AM, Xavion wrote:
> My Microdia (SN9C201) webcam was working in Linux, but it has been
> failing lately.  Take a look at the attached snapshot to see what I
> mean.  It's like that all the time in Linux these days, but it works
> perfectly in Windows.

Thanks for the picture that truely says more then a 1000 words
(Dutch proverb), the problem is that the new bandwidth allocation
code added to gspca in 3.2 does not allocate enough bandwidth for
the sn9c20x. 3.3 has a fix for this.

Regards,

Hans

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Xavion]

Hi Hans

Thanks for letting me know that this problem will be fixed in Linux
v3.3.  It could be several weeks before my distribution releases that
kernel.  Dropping back to Linux v3.1 isn't an option, as my NVIDIA
driver requires Linux v3.2.  Can the fix for this problem also be
applied to Linux v3.2.x manually?  If so, please email me the
corresponding patch file and I'll test it here.

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Jean-Francois Moine]

On Sun, 4 Mar 2012 11:25:19 +1100
Xavion <xavion.0@gmail.com> wrote:

> Thanks for letting me know that this problem will be fixed in Linux
> v3.3.  It could be several weeks before my distribution releases that
> kernel.  Dropping back to Linux v3.1 isn't an option, as my NVIDIA
> driver requires Linux v3.2.  Can the fix for this problem also be
> applied to Linux v3.2.x manually?  If so, please email me the
> corresponding patch file and I'll test it here.

Hi,

You may take the gspca test version from my site: it is smaller.

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

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Xavion]

Hi Jean-Francois

I can confirm that GSPCA v2.15.1 removes the bad pixels when I use
Cheese or VLC.  However, I'm sorry to report that the Motion problems
unfortunately still remain.  Is there something else I must do to
overcome the below errors?  I'm happy to keep testing newer GSPCA
versions for you until we get this fixed.


`--> tail /var/log/kernel.log
Mar  5 08:25:52 Desktop kernel: [ 6673.781987] gspca_main: frame
overflow 156309 > 155648
Mar  5 08:25:52 Desktop kernel: [ 6673.813992] gspca_main: frame
overflow 156309 > 155648
Mar  5 08:25:53 Desktop kernel: [ 6673.849986] gspca_main: frame
overflow 155693 > 155648
Mar  5 08:25:53 Desktop kernel: [ 6673.881989] gspca_main: frame
overflow 156021 > 155648
Mar  5 08:25:53 Desktop kernel: [ 6673.917991] gspca_main: frame
overflow 156309 > 155648
Mar  5 08:25:53 Desktop kernel: [ 6673.949993] gspca_main: frame
overflow 156309 > 155648
Mar  5 08:25:53 Desktop kernel: [ 6673.985990] gspca_main: frame
overflow 156309 > 155648
Mar  5 08:25:53 Desktop kernel: [ 6674.021981] gspca_main: frame
overflow 156309 > 155648
Mar  5 08:25:53 Desktop kernel: [ 6674.053985] gspca_main: frame
overflow 156309 > 155648
Mar  5 08:25:53 Desktop kernel: [ 6674.089989] gspca_main: frame
overflow 156309 > 155648


`--> tail /var/log/errors.log
Mar  5 08:24:16 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument
Mar  5 08:24:16 Desktop motion: [1] Video device fatal error - Closing
video device
Mar  5 08:24:20 Desktop motion: [1] Retrying until successful
connection with camera
Mar  5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO
(s->pframe 3): Input/output error
Mar  5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument
Mar  5 08:24:27 Desktop motion: [1] Video device fatal error - Closing
video device
Mar  5 08:24:30 Desktop motion: [1] Retrying until successful
connection with camera
Mar  5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO
(s->pframe 0): Input/output error
Mar  5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument
Mar  5 08:24:33 Desktop motion: [1] Video device fatal error - Closing
video device

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Hans de Goede]

Hi,

On 03/04/2012 10:58 PM, Xavion wrote:
> Hi Jean-Francois
>
> I can confirm that GSPCA v2.15.1 removes the bad pixels when I use
> Cheese or VLC.  However, I'm sorry to report that the Motion problems
> unfortunately still remain.  Is there something else I must do to
> overcome the below errors?  I'm happy to keep testing newer GSPCA
> versions for you until we get this fixed.

I guess that motion is using the JPG compressed frames rather then
the i420 like special format these cameras also support, and it looks
like we don't reserve enoug space to buffer these frames. To fix this
we need to enlarge the size we reserve per frame in the sn9c20x driver,
edit sn9c20x.c and search for vga_mode, in that table you will
find a factor "4 / 8" (its in there 3 times), change all 3 occurences
to "5 / 8" and try again, then "6 / 8", etc.

Normally I would be suspicious about SOF / EOF detection when we
need such a factor, but the timestamps in your log exactly match 30
fps, so that seems to be fine. And in my experience with the USB bandwidth
stuff the sn9c20x does seem to compress less then other JPG cams, so
it makes sense that it needs bigger buffers to store the frames too.

Alternatively you can try if motion can be made to use a different format
then JPG, by forcing it to use libv4l by starting it like this:
LD_PRELOAD=/usr/lib/libv4l/v4l1-compat.so motion

Note if you're on a rpm based 64 bit distro and motion is 64 bit too
that should be:
LD_PRELOAD=/usr/lib64/libv4l/v4l1-compat.so motion

But that would just be working around the issue, it is better to
fix the issue with using the JPG mode of the camera instead.

Regards,

Hans





>
>
> `-->  tail /var/log/kernel.log
> Mar  5 08:25:52 Desktop kernel: [ 6673.781987] gspca_main: frame
> overflow 156309>  155648
> Mar  5 08:25:52 Desktop kernel: [ 6673.813992] gspca_main: frame
> overflow 156309>  155648
> Mar  5 08:25:53 Desktop kernel: [ 6673.849986] gspca_main: frame
> overflow 155693>  155648
> Mar  5 08:25:53 Desktop kernel: [ 6673.881989] gspca_main: frame
> overflow 156021>  155648
> Mar  5 08:25:53 Desktop kernel: [ 6673.917991] gspca_main: frame
> overflow 156309>  155648
> Mar  5 08:25:53 Desktop kernel: [ 6673.949993] gspca_main: frame
> overflow 156309>  155648
> Mar  5 08:25:53 Desktop kernel: [ 6673.985990] gspca_main: frame
> overflow 156309>  155648
> Mar  5 08:25:53 Desktop kernel: [ 6674.021981] gspca_main: frame
> overflow 156309>  155648
> Mar  5 08:25:53 Desktop kernel: [ 6674.053985] gspca_main: frame
> overflow 156309>  155648
> Mar  5 08:25:53 Desktop kernel: [ 6674.089989] gspca_main: frame
> overflow 156309>  155648
>
>
> `-->  tail /var/log/errors.log
> Mar  5 08:24:16 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument
> Mar  5 08:24:16 Desktop motion: [1] Video device fatal error - Closing
> video device
> Mar  5 08:24:20 Desktop motion: [1] Retrying until successful
> connection with camera
> Mar  5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO
> (s->pframe 3): Input/output error
> Mar  5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument
> Mar  5 08:24:27 Desktop motion: [1] Video device fatal error - Closing
> video device
> Mar  5 08:24:30 Desktop motion: [1] Retrying until successful
> connection with camera
> Mar  5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO
> (s->pframe 0): Input/output error
> Mar  5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument
> Mar  5 08:24:33 Desktop motion: [1] Video device fatal error - Closing
> video device
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Jean-Francois Moine]

On Mon, 05 Mar 2012 09:33:18 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> I guess that motion is using the JPG compressed frames rather then
> the i420 like special format these cameras also support, and it looks
> like we don't reserve enoug space to buffer these frames. To fix this
> we need to enlarge the size we reserve per frame in the sn9c20x driver,
> edit sn9c20x.c and search for vga_mode, in that table you will
> find a factor "4 / 8" (its in there 3 times), change all 3 occurences
> to "5 / 8" and try again, then "6 / 8", etc.
> 
> Normally I would be suspicious about SOF / EOF detection when we
> need such a factor, but the timestamps in your log exactly match 30
> fps, so that seems to be fine. And in my experience with the USB bandwidth
> stuff the sn9c20x does seem to compress less then other JPG cams, so
> it makes sense that it needs bigger buffers to store the frames too.

Hi Hans,

The JPEG compression quality of the sn9c20x is 95%. That's why the
frames are so big. Then, if the quality is not settable, I wonder why
to use the JPEG format.

BTW, I wonder also about the SN9C20X_I420: this format asks for a
buffer greater than the native image. So, as these webcams are USB 2.0,
shouldn't it be simpler to have only Bayer in the driver?

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

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Hans de Goede]

Hi,

On 03/05/2012 01:03 PM, Jean-Francois Moine wrote:
> On Mon, 05 Mar 2012 09:33:18 +0100
> Hans de Goede<hdegoede@redhat.com>  wrote:
>
>> I guess that motion is using the JPG compressed frames rather then
>> the i420 like special format these cameras also support, and it looks
>> like we don't reserve enoug space to buffer these frames. To fix this
>> we need to enlarge the size we reserve per frame in the sn9c20x driver,
>> edit sn9c20x.c and search for vga_mode, in that table you will
>> find a factor "4 / 8" (its in there 3 times), change all 3 occurences
>> to "5 / 8" and try again, then "6 / 8", etc.
>>
>> Normally I would be suspicious about SOF / EOF detection when we
>> need such a factor, but the timestamps in your log exactly match 30
>> fps, so that seems to be fine. And in my experience with the USB bandwidth
>> stuff the sn9c20x does seem to compress less then other JPG cams, so
>> it makes sense that it needs bigger buffers to store the frames too.
>
> Hi Hans,
>
> The JPEG compression quality of the sn9c20x is 95%. That's why the
> frames are so big. Then, if the quality is not settable, I wonder why
> to use the JPEG format.

I think the quality is settable, and we are just not setting it to a very
useful value. I'm afraid I don't have time to work on this atm, but if you
are willing to take a shot at this, then I can test (I've such a camera).

I'll send you a private mail with info on how to set the compression
ratio.

> BTW, I wonder also about the SN9C20X_I420: this format asks for a
> buffer greater than the native image.

Yes, but then the data is ready to use, since most apps actuall want i420,
where as raw bayer needs a lot of CPU intensive processing before we get
useful data out of it.

Regards,

Hans

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Jean-Francois Moine]

On Mon, 5 Mar 2012 08:58:30 +1100
Xavion <xavion.0@gmail.com> wrote:

> I can confirm that GSPCA v2.15.1 removes the bad pixels when I use
> Cheese or VLC.  However, I'm sorry to report that the Motion problems
> unfortunately still remain.  Is there something else I must do to
> overcome the below errors?  I'm happy to keep testing newer GSPCA
> versions for you until we get this fixed.

Hi again,

I looked at the driver again, and thanks to Hans, I found you could
easily lower the JPEG compression quality and stop buffer overflow.

At line 2093 of build/sn9c20x.c (gspca test), there is:

	sd->quality = 95;

Changing '95' to '80' should be enough.

I will add this parameter as a video control as soon as it will be
standard. Then you could adjust it with an external program as v4l2ucp.

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

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Xavion]

Hi Guys

Thanks very much for the follow-up emails.  Our time-zone differences
prevented me from replying sooner.  I'm guessing you guys are both in
Europe, whereas I'm down and across in Australia.

As I plan to use this webcam for home security, I would prefer to keep
the JPEG quality at or above 90% if possible.  This is because it'd be
difficult enough to see a burglar's face clearly at 640x480 with
lossless quality.

The good news is that the nasty errors I was getting yesterday have
magically disappeared overnight!  All I'm seeing today (at 90% and 75%
quality) is what look to be non-fatal errors, since Motion seems to
work correctly.

    root@Desktop /etc/motion # tail /var/log/kernel.log
    Mar  6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC
data error: [0] len=0, status=-18
    Mar  6 08:34:17 Desktop kernel: [ 7240.125172] gspca_main: ISOC
data error: [1] len=0, status=-18
    Mar  6 08:36:40 Desktop kernel: [ 7382.545241] gspca_main: ISOC
data error: [0] len=0, status=-18
    Mar  6 08:36:40 Desktop kernel: [ 7382.545246] gspca_main: ISOC
data error: [1] len=0, status=-18
    Mar  6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480
    Mar  6 08:40:12 Desktop kernel: [ 7594.685124] gspca_main: ISOC
data error: [0] len=0, status=-18
    Mar  6 08:40:12 Desktop kernel: [ 7594.685129] gspca_main: ISOC
data error: [1] len=0, status=-18
    Mar  6 08:42:37 Desktop kernel: [ 7739.715758] gspca_sn9c20x: Set 640x480
    Mar  6 08:46:06 Desktop kernel: [ 7948.598533] gspca_main: ISOC
data error: [0] len=0, status=-18
    Mar  6 08:46:06 Desktop kernel: [ 7948.598538] gspca_main: ISOC
data error: [1] len=0, status=-18

In fairness to Motion, the default JPEG quality listed in its
configuration file is only 75%.  I had upped this to 90% for clarity,
but subsequently reverting to the default configuration file didn't
stop these errors.

They also remained after I increased the three "vga_mode" ratios to "6
/ 8" or changed Line 2093 of "sn9c20x.c" to "sd->quality = 75;".
Entering either of the following commands before starting Motion
didn't make any difference either.
    export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
    export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so

The other thing I'm wondering about is how to force SXGA (1280x1024)
mode to be used.  I've set the 'width' and 'height' variables in the
Motion configuration file correctly, but I still see the following
kernel output:
    Mar  6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480

I should note that Motion defaults to "V4L2_PIX_FMT_YUV420" in its
configuration file, which is what I'd been using until now.  From the
look of the code in the "sn9c20x.c" file, I must use
"V4L2_PIX_FMT_SBGGR8" to get the 1280x1024 resolution.

After making this change, I still saw "Set 640x480" in the kernel
output.  How can the above errors be overcome and how can I force SXGA
mode to be used by my applications?  Thanks again for all of the
assistance you've given me so far.

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Hans de Goede]

Hi,

On 03/06/2012 01:44 AM, Xavion wrote:
> Hi Guys
>
> Thanks very much for the follow-up emails.  Our time-zone differences
> prevented me from replying sooner.  I'm guessing you guys are both in
> Europe, whereas I'm down and across in Australia.
>
> As I plan to use this webcam for home security, I would prefer to keep
> the JPEG quality at or above 90% if possible.  This is because it'd be
> difficult enough to see a burglar's face clearly at 640x480 with
> lossless quality.
>
> The good news is that the nasty errors I was getting yesterday have
> magically disappeared overnight!

That is likely because the scene you're pointing at (or the lighting
conditions) have changed, not all pictures compress equally well
with JPEG. If you point the camera at the same scene as when you were
getting these errors (with similar, good, lighting conditions) you'll
likely see those errors re-surface.

> All I'm seeing today (at 90% and 75%
> quality) is what look to be non-fatal errors, since Motion seems to
> work correctly.
>
>      root@Desktop /etc/motion # tail /var/log/kernel.log
>      Mar  6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC
> data error: [0] len=0, status=-18
>      Mar  6 08:34:17 Desktop kernel: [ 7240.125172] gspca_main: ISOC
> data error: [1] len=0, status=-18
>      Mar  6 08:36:40 Desktop kernel: [ 7382.545241] gspca_main: ISOC
> data error: [0] len=0, status=-18
>      Mar  6 08:36:40 Desktop kernel: [ 7382.545246] gspca_main: ISOC
> data error: [1] len=0, status=-18
>      Mar  6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480
>      Mar  6 08:40:12 Desktop kernel: [ 7594.685124] gspca_main: ISOC
> data error: [0] len=0, status=-18
>      Mar  6 08:40:12 Desktop kernel: [ 7594.685129] gspca_main: ISOC
> data error: [1] len=0, status=-18
>      Mar  6 08:42:37 Desktop kernel: [ 7739.715758] gspca_sn9c20x: Set 640x480
>      Mar  6 08:46:06 Desktop kernel: [ 7948.598533] gspca_main: ISOC
> data error: [0] len=0, status=-18
>      Mar  6 08:46:06 Desktop kernel: [ 7948.598538] gspca_main: ISOC
> data error: [1] len=0, status=-18

Hmm, error -18 is EXDEV, which according to Documentation/usb/error-codes.txt is:

-EXDEV                  ISO transfer only partially completed
                         (only set in iso_frame_desc[n].status, not urb->status)

I've seen those before, and I think we should simply ignore them rather then
log an error for them. Jean-Francois, what do you think?

> In fairness to Motion, the default JPEG quality listed in its
> configuration file is only 75%.  I had upped this to 90% for clarity,
> but subsequently reverting to the default configuration file didn't
> stop these errors.

That is a different JPG setting, that is the compression quality for the
JPEG's motion saves to disk if it detects motion. We're are talking about
the compression quality of the JPEG's going over the USB wire, which is
controller by the driver, not by motion.

> They also remained after I increased the three "vga_mode" ratios to "6
> / 8" or changed Line 2093 of "sn9c20x.c" to "sd->quality = 75;".

You mean the -18 error remain, right, that is expected, the
ratios / sd->quality only fix the errors you were seeing previously.

> Entering either of the following commands before starting Motion
> didn't make any difference either.
>      export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
>      export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so
>
> The other thing I'm wondering about is how to force SXGA (1280x1024)
> mode to be used.  I've set the 'width' and 'height' variables in the
> Motion configuration file correctly, but I still see the following
> kernel output:
>      Mar  6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480
>
> I should note that Motion defaults to "V4L2_PIX_FMT_YUV420" in its
> configuration file, which is what I'd been using until now.  From the
> look of the code in the "sn9c20x.c" file, I must use
> "V4L2_PIX_FMT_SBGGR8" to get the 1280x1024 resolution.

For sxga mode you will need to use libv4l, but I doubt if your camera supports
it at all, most don't. What does dmesg say immediately after unplugging and
replugging the camera?

Regards,

Hans

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Xavion]

Hi Hans

>> The good news is that the nasty errors I was getting yesterday have
>> magically disappeared overnight!
>
> That is likely because the scene you're pointing at (or the lighting
> conditions) have changed, not all pictures compress equally well
> with JPEG. If you point the camera at the same scene as when you were
> getting these errors (with similar, good, lighting conditions) you'll
> likely see those errors re-surface.

At the time, I thought it was probably just because I hadn't rebooted
my computer after installing GSPCA v2.15.1 the previous day.  If those
nastier errors resurface, I'll test whether they can be suppressed by
making those changes to "sn9c20x.c" again.

>>     root@Desktop /etc/motion # tail /var/log/kernel.log
>>     Mar  6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC
>> data error: [0] len=0, status=-18
>>    ...
>
> Hmm, error -18 is EXDEV, which according to
> Documentation/usb/error-codes.txt is:
>
> -EXDEV                  ISO transfer only partially completed
>                        (only set in iso_frame_desc[n].status, not
> urb->status)
>
> I've seen those before, and I think we should simply ignore them rather then
> log an error for them. Jean-Francois, what do you think?

I'll let you guys decide what to do about this, but remember that I'm
here to help if you need more testing done.  If you want my opinion,
I'd be leaning towards trying to prevent any errors that appear
regularly.

>> In fairness to Motion, the default JPEG quality listed in its
>> configuration file is only 75%.  I had upped this to 90% for clarity,
>> but subsequently reverting to the default configuration file didn't
>> stop these errors.
>
> That is a different JPG setting, that is the compression quality for the
> JPEG's motion saves to disk if it detects motion. We're are talking about
> the compression quality of the JPEG's going over the USB wire, which is
> controller by the driver, not by motion.

I thought that was probably the case, but I left open the possibility
that Motion could've been telling GSPCA what JPEG setting to use for
USB transfers.

>> They also remained after I increased the three "vga_mode" ratios to "6
>> / 8" or changed Line 2093 of "sn9c20x.c" to "sd->quality = 75;".
>
> You mean the -18 error remain, right, that is expected, the
> ratios / sd->quality only fix the errors you were seeing previously.

Yes, I was only seeing the "-18" error message yesterday.  I knew that
the "vga_mode" and "sd->quality" suggestions were intended for the
other (nastier) errors.  As I couldn't be sure that the "-18" error
wasn't somehow related, I decided to test those suggestions on it as
well.

>> Entering either of the following commands before starting Motion
>> didn't make any difference either.
>>     export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
>>     export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so
>>
>> The other thing I'm wondering about is how to force SXGA (1280x1024)
>> mode to be used.  I've set the 'width' and 'height' variables in the
>> Motion configuration file correctly, but I still see the following
>> kernel output:
>>     Mar  6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set
>> 640x480
>>
>> I should note that Motion defaults to "V4L2_PIX_FMT_YUV420" in its
>> configuration file, which is what I'd been using until now.  From the
>> look of the code in the "sn9c20x.c" file, I must use
>> "V4L2_PIX_FMT_SBGGR8" to get the 1280x1024 resolution.
>
> For sxga mode you will need to use libv4l, but I doubt if your camera
> supports
> it at all, most don't. What does dmesg say immediately after unplugging and
> replugging the camera?

The software I use to control my webcam in Windows can increase the
snapshot zoom to what it calls 'SXGA'.  Closer inspection reveals that
it's actually just doubling the 640x480 image - via nearest-neighbour
interpolation - to get a rather pixelated 1280x960.

This isn't even the proper SXGA resolution, which is supposed to be
1280x1024.  The Sonix website claims that their SN9C201 webcam can
provide up to a 1.3 MP (SXGA) video size!  Do you happen to know of
any inexpensive webcams that are capable of true SXGA in Linux?

    `--> lsusb | grep Cam
    Bus 001 Device 006: ID 0c45:627b Microdia PC Camera (SN9C201 + OV7660)

    `--> dmesg
    ...
    [ 5155.396674] usb 5-5.5: USB disconnect, device number 5
    [ 5155.396835] gspca_main: video0 disconnect
    [ 5155.440019] gspca_main: video0 released
    [ 5159.946302] usb 5-5.5: new high-speed USB device number 6 using ehci_hcd
    [ 5160.045863] gspca_main: sn9c20x-2.15.1 probing 0c45:627b
    [ 5160.071035] gspca_sn9c20x: OV7660 sensor detected
    [ 5160.071146] input: sn9c20x as
/devices/pci0000:00/0000:00:1d.7/usb5/5-5/5-5.5/input/input8
    [ 5160.071277] gspca_main: video0 created

As mentioned above, I had already tried exporting "LD_PRELOAD" for
both V4L v1 and v2 beforehand.  Furthermore, the two
"V4L2_PIX_FMT_..." Motion settings I've used both begin with "V4L2".
Let me know if there's anything else I should do to ensure that Motion
is using V4L.

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Theodore Kilgore]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5737 bytes --]



On Wed, 7 Mar 2012, Xavion wrote:

> Hi Hans
> 
> >> The good news is that the nasty errors I was getting yesterday have
> >> magically disappeared overnight!
> >
> > That is likely because the scene you're pointing at (or the lighting
> > conditions) have changed, not all pictures compress equally well
> > with JPEG. If you point the camera at the same scene as when you were
> > getting these errors (with similar, good, lighting conditions) you'll
> > likely see those errors re-surface.
> 
> At the time, I thought it was probably just because I hadn't rebooted
> my computer after installing GSPCA v2.15.1 the previous day.  If those
> nastier errors resurface, I'll test whether they can be suppressed by
> making those changes to "sn9c20x.c" again.
> 
> >>     root@Desktop /etc/motion # tail /var/log/kernel.log
> >>     Mar  6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC
> >> data error: [0] len=0, status=-18
> >>    ...
> >
> > Hmm, error -18 is EXDEV, which according to
> > Documentation/usb/error-codes.txt is:
> >
> > -EXDEV                  ISO transfer only partially completed
> >                        (only set in iso_frame_desc[n].status, not
> > urb->status)
> >
> > I've seen those before, and I think we should simply ignore them rather then
> > log an error for them. Jean-Francois, what do you think?
> 
> I'll let you guys decide what to do about this, but remember that I'm
> here to help if you need more testing done.  If you want my opinion,
> I'd be leaning towards trying to prevent any errors that appear
> regularly.
> 
> >> In fairness to Motion, the default JPEG quality listed in its
> >> configuration file is only 75%.  I had upped this to 90% for clarity,
> >> but subsequently reverting to the default configuration file didn't
> >> stop these errors.
> >
> > That is a different JPG setting, that is the compression quality for the
> > JPEG's motion saves to disk if it detects motion. We're are talking about
> > the compression quality of the JPEG's going over the USB wire, which is
> > controller by the driver, not by motion.
> 
> I thought that was probably the case, but I left open the possibility
> that Motion could've been telling GSPCA what JPEG setting to use for
> USB transfers.
> 
> >> They also remained after I increased the three "vga_mode" ratios to "6
> >> / 8" or changed Line 2093 of "sn9c20x.c" to "sd->quality = 75;".
> >
> > You mean the -18 error remain, right, that is expected, the
> > ratios / sd->quality only fix the errors you were seeing previously.
> 
> Yes, I was only seeing the "-18" error message yesterday.  I knew that
> the "vga_mode" and "sd->quality" suggestions were intended for the
> other (nastier) errors.  As I couldn't be sure that the "-18" error
> wasn't somehow related, I decided to test those suggestions on it as
> well.
> 
> >> Entering either of the following commands before starting Motion
> >> didn't make any difference either.
> >>     export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
> >>     export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so
> >>
> >> The other thing I'm wondering about is how to force SXGA (1280x1024)
> >> mode to be used.  I've set the 'width' and 'height' variables in the
> >> Motion configuration file correctly, but I still see the following
> >> kernel output:
> >>     Mar  6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set
> >> 640x480
> >>
> >> I should note that Motion defaults to "V4L2_PIX_FMT_YUV420" in its
> >> configuration file, which is what I'd been using until now.  From the
> >> look of the code in the "sn9c20x.c" file, I must use
> >> "V4L2_PIX_FMT_SBGGR8" to get the 1280x1024 resolution.
> >
> > For sxga mode you will need to use libv4l, but I doubt if your camera
> > supports
> > it at all, most don't. What does dmesg say immediately after unplugging and
> > replugging the camera?
> 
> The software I use to control my webcam in Windows can increase the
> snapshot zoom to what it calls 'SXGA'.  Closer inspection reveals that
> it's actually just doubling the 640x480 image - via nearest-neighbour
> interpolation - to get a rather pixelated 1280x960.

This kind of fudging is, unfortunately, very typical. Lots of cameras on 
the market have things like that written on the package. If there is any 
residual truth in what is written there at all, it says something like 
"Interpolated XxY resolution" which is a mealy-mouthed admission of that 
kind of resolution-inflation when you see it. But sometimes they just 
plain lie. 

 
> This isn't even the proper SXGA resolution, which is supposed to be
> 1280x1024.  The Sonix website claims that their SN9C201 webcam can
> provide up to a 1.3 MP (SXGA) video size!  

Too typical. 

Do you happen to know of
> any inexpensive webcams that are capable of true SXGA in Linux?

Unfortunately, not. But I could not resist pointing out that the kind of 
hype that you have described is all too typical of the marketing for such 
merchandise. 

As to getting that kind of resolution out of a webcam, though, it would be 
a rather tough go due to the amount of data which has to pass over the 
wire even if it is compressed data. The frame rate would be pretty 
atrocious. Therefore, you are probably not going to see that kind 
of resolution in an inexpensive webcam, at least until USB 3 comes 
into common use. 

Perhaps for now if you want that kind of resolution and do not care about 
the frame rate very much, you would be better off to buy a slightly 
fancier camera and do something like using gphoto2 to take timed shots.

Just a suggestion. And thanks for the patience to work through the 
problem. This thread has been an interesting read.

Theodore Kilgore

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Jean-Francois Moine]

On Wed, 7 Mar 2012 09:59:28 +1100
Xavion <xavion.0@gmail.com> wrote:

> >>     root@Desktop /etc/motion # tail /var/log/kernel.log
> >>     Mar  6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC
> >> data error: [0] len=0, status=-18
> >>    ...  
> >
> > Hmm, error -18 is EXDEV, which according to
> > Documentation/usb/error-codes.txt is:
> >
> > -EXDEV                  ISO transfer only partially completed
> >                        (only set in iso_frame_desc[n].status, not
> > urb->status)
> >
> > I've seen those before, and I think we should simply ignore them rather then
> > log an error for them. Jean-Francois, what do you think?  
> 
> I'll let you guys decide what to do about this, but remember that I'm
> here to help if you need more testing done.  If you want my opinion,
> I'd be leaning towards trying to prevent any errors that appear
> regularly.

Hi,

It seems that the webcams handled by the driver sn9c20x work the same
as the ones handled by sonixj. In this last driver, I adjust the JPEG
compression to avoid the errors "USB FIFO full", and I think that these
errors also raise the URB error -18 with the sn9c20x. I will need some
time to put a same code into the sn9c20x, then I'd be glad to have it
tested.

There was an other problem in the driver sonixj: the end of frame
marker was not always at the right place. Xavion, as you have
ms-windows, may you do some USB traces with this system? I need a
capture sequence of about 15 seconds (not more) with big luminosity
changes.

> This isn't even the proper SXGA resolution, which is supposed to be
> 1280x1024.  The Sonix website claims that their SN9C201 webcam can
> provide up to a 1.3 MP (SXGA) video size!  Do you happen to know of
> any inexpensive webcams that are capable of true SXGA in Linux?
> 
>     `--> lsusb | grep Cam
>     Bus 001 Device 006: ID 0c45:627b Microdia PC Camera (SN9C201 + OV7660)

The sensor ov7660 can do VGA only (640x480).

Otherwise, I uploaded a new gspca test version (2.15.3) with the JPEG compression control (default 80%). May you try it?

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

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Xavion]

Hi Theodore

> As to getting that kind of resolution out of a webcam, though, it would be
> a rather tough go due to the amount of data which has to pass over the
> wire even if it is compressed data. The frame rate would be pretty
> atrocious. Therefore, you are probably not going to see that kind
> of resolution in an inexpensive webcam, at least until USB 3 comes
> into common use.

Thanks for offering your thoughts on this matter.  It looks like I'll
have to keep checking eBay for cheap USB v3 (HD) webcams periodically.
 For the record, I've only got Motion set to capture four frames per
second at the moment.

> Perhaps for now if you want that kind of resolution and do not care about
> the frame rate very much, you would be better off to buy a slightly
> fancier camera and do something like using gphoto2 to take timed shots.

I prefer the idea of captured motion to that of timed snapshots.  The
captured images and videos are automatically uploaded to my Dropbox
account.  As I'm only a 'free' user, I must limit the storage space
that these files consume.

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Xavion]

Hi Jean-Francois

> It seems that the webcams handled by the driver sn9c20x work the same
> as the ones handled by sonixj. In this last driver, I adjust the JPEG
> compression to avoid the errors "USB FIFO full", and I think that these
> errors also raise the URB error -18 with the sn9c20x. I will need some
> time to put a same code into the sn9c20x, then I'd be glad to have it
> tested.
>
> There was an other problem in the driver sonixj: the end of frame
> marker was not always at the right place. Xavion, as you have
> ms-windows, may you do some USB traces with this system? I need a
> capture sequence of about 15 seconds (not more) with big luminosity
> changes.

I've never needed to capture USB data manually until now, so I'm not
sure of which (free) Windows application I should use.  I'm assuming
that a software-only analyser would be good enough to provide the
information you're wanting.

I'm guessing that continuously blocking and unblocking the webcam's
vision will suffice for big luminosity changes.  Let me know if that's
not going to cut it and I'll repeatedly toggle the switch for the
ceiling light in my lounge-room (at night) instead.

I just tried to get the data using three different USB packet
sniffers.  The unfortunate results on my 32-bit Windows XP laptop are
listed below.  BTW, what size should the log-file have been after
capturing the fifteen seconds you're wanting?
* BusDog: Couldn't find the webcam device
* SniffUSB: The log file was 100+ MiB in size
* SnoopyPro: Couldn't capture any packets

> The sensor ov7660 can do VGA only (640x480).
>
> Otherwise, I uploaded a new gspca test version (2.15.3) with the JPEG compression control (default 80%). May you try it?

I've downloaded and tested GSPCA v2.15.3.  I'm sorry to nitpick, but
you still had "2.15.1" listed near the top of the "gspca.h" file.  I'm
also sorry to report that GSPCA v2.15.3 caused the following fatal
errors with my SN9C201 webcam:

    `--> tail /var/log/kernel.log
    Mar  8 10:21:09 Desktop kernel: [13758.712077] usb 1-5.5: new
high-speed USB device number 10 using ehci_hcd
    Mar  8 10:21:09 Desktop kernel: [13758.852838] Linux media interface: v0.10
    Mar  8 10:21:09 Desktop kernel: [13758.857354] Linux video capture
interface: v2.00
    Mar  8 10:21:09 Desktop kernel: [13758.858018] gspca_main: v2.15.3
registered
    Mar  8 10:21:09 Desktop kernel: [13758.858357] gspca_main:
gspca_sn9c20x-2.15.3 probing 0c45:627b
    Mar  8 10:21:09 Desktop kernel: [13758.886556] gspca_sn9c20x:
OV7660 sensor detected
    Mar  8 10:21:09 Desktop kernel: [13758.886647] input:
gspca_sn9c20x as
/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5.5/input/input16
    Mar  8 10:21:09 Desktop kernel: [13758.886791] gspca_main: video0 created
    Mar  8 10:21:09 Desktop kernel: [13758.886823] usbcore: registered
new interface driver gspca_sn9c20x
    Mar  8 10:22:04 Desktop kernel: [13813.347291] gspca_sn9c20x: Set 640x480

    `--> tail /var/log/errors.log
    Mar  8 10:24:09 Desktop motion: [1] Error starting stream
VIDIOC_STREAMON: Input/output error
    Mar  8 10:24:09 Desktop motion: [1] ioctl (VIDIOCGCAP):
Inappropriate ioctl for device
    Mar  8 10:24:09 Desktop motion: [1] Could not fetch initial image
from camera
    Mar  8 10:24:09 Desktop motion: [1] Motion continues using width
and height from config file(s)
    Mar  8 10:24:10 Desktop motion: [1] Retrying until successful
connection with camera
    Mar  8 10:24:10 Desktop motion: [1] Error requesting buffers 4 for
memory map. VIDIOC_REQBUFS: Device or resource busy
    Mar  8 10:24:10 Desktop motion: [1] ioctl (VIDIOCGCAP):
Inappropriate ioctl for device
    Mar  8 10:24:20 Desktop motion: [1] Retrying until successful
connection with camera
    Mar  8 10:24:20 Desktop motion: [1] Error requesting buffers 4 for
memory map. VIDIOC_REQBUFS: Device or resource busy
    Mar  8 10:24:20 Desktop motion: [1] ioctl (VIDIOCGCAP):
Inappropriate ioctl for device

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Theodore Kilgore]

On Thu, 8 Mar 2012, Xavion wrote:

> Hi Theodore
> 
> > As to getting that kind of resolution out of a webcam, though, it would be
> > a rather tough go due to the amount of data which has to pass over the
> > wire even if it is compressed data. The frame rate would be pretty
> > atrocious. Therefore, you are probably not going to see that kind
> > of resolution in an inexpensive webcam, at least until USB 3 comes
> > into common use.
> 
> Thanks for offering your thoughts on this matter.  

You are welcome. 

It looks like I'll
> have to keep checking eBay for cheap USB v3 (HD) webcams periodically.

Which somebody will need to support because they will probably not work 
out of the box with an OEM driver CD ;-)

>  For the record, I've only got Motion set to capture four frames per
> second at the moment.
> 
> > Perhaps for now if you want that kind of resolution and do not care about
> > the frame rate very much, you would be better off to buy a slightly
> > fancier camera and do something like using gphoto2 to take timed shots.
> 
> I prefer the idea of captured motion to that of timed snapshots.  The
> captured images and videos are automatically uploaded to my Dropbox
> account.  As I'm only a 'free' user, I must limit the storage space
> that these files consume.
> 

Some of the cheap cameras do work pretty well, actually. But as far as I 
know any resolution better than 640*480 seems to be pretty unusual. Lots 
of "interpolated" higher resolution meaning they have inflated the 
pictures, of course. But some of the 640x480 cameras do better than 
others. And also I should point out that if 4 fps is OK with you then some 
of the cameras do not even do compression. If you could get hold of an old 
SQ905 camera that will do 640x480 it runs on bulk transport and there is 
no compression of frame data at all. Also, what is interesting is that 
with all the cheap cameras they cut corners, of course. But the SQ905 
cameras always seemed to me to tend to have better optics than a lot of 
the other cheap cams. Where they really cut down on features was with the 
controller chip. It will do practically nothing compared to some others. 
The SQ905 used to be advertised as the cheapest camera controller chip on 
the market, once upon a time. But the images one gets from those cameras 
sometimes are not half bad.

Also I should mention that if one wants to get better images out then it 
is best somehow to capture and save the raw data and process it later. 
This is true for any camera which either produces an uncompressed bitmap 
raw image, and also for any camera which does compression of said bitmap 
image before sending it down to the computer. Everything but JPEG, pretty 
much. Why is this? Because the image processing used with webcams must 
necessarily have speed as the number one priority, else the frame rate 
suffers severely. If one is not thus constrained, it is possible to do a 
much better job with that raw data. But remember that you can maximize 
image quality, or you can maximize frame rate. Choose one of the two.

Theodore Kilgore

Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore

[Xavion]

Hi Theodore

> > It looks like I'll have to keep checking eBay for cheap USB v3 (HD)
> > webcams periodically.
>
> Which somebody will need to support because they will probably not work
> out of the box with an OEM driver CD ;-)

Ah yes, there is that aspect to think about before making a purchase
:-).  Actually, I think Linus will be pretty keen to rush support for
USB v3 webcams into the kernel.  Hopefully it won't take too long for
a few cheapies to work in Linux.

> Some of the cheap cameras do work pretty well, actually. But as far as I
> know any resolution better than 640*480 seems to be pretty unusual. Lots
> of "interpolated" higher resolution meaning they have inflated the
> pictures, of course. But some of the 640x480 cameras do better than
> others. And also I should point out that if 4 fps is OK with you then some
> of the cameras do not even do compression. If you could get hold of an old
> SQ905 camera that will do 640x480 it runs on bulk transport and there is
> no compression of frame data at all. Also, what is interesting is that
> with all the cheap cameras they cut corners, of course. But the SQ905
> cameras always seemed to me to tend to have better optics than a lot of
> the other cheap cams. Where they really cut down on features was with the
> controller chip. It will do practically nothing compared to some others.
> The SQ905 used to be advertised as the cheapest camera controller chip on
> the market, once upon a time. But the images one gets from those cameras
> sometimes are not half bad.

Thanks for letting me know about that model.  I think I'll be able to
stay with my SN9C201 for now, especially since I've started using
Motion's auto-brightness setting.  It almost seemed like the sun was
in the room with me last night :-).

> Also I should mention that if one wants to get better images out then it
> is best somehow to capture and save the raw data and process it later.
> This is true for any camera which either produces an uncompressed bitmap
> raw image, and also for any camera which does compression of said bitmap
> image before sending it down to the computer. Everything but JPEG, pretty
> much. Why is this? Because the image processing used with webcams must
> necessarily have speed as the number one priority, else the frame rate
> suffers severely. If one is not thus constrained, it is possible to do a
> much better job with that raw data. But remember that you can maximize
> image quality, or you can maximize frame rate. Choose one of the two.

Yeah, I had a feeling that would be the case.  The following is an
extract from Motion's configuration file.  If I want to maximise
quality, which of these options do you think I should choose?  As you
can see, I've been using the default one (8) lately.

# v4l2_palette allows to choose preferable palette to be use by motion
# to capture from those supported by your videodevice. (default: 8)
# E.g. if your videodevice supports both V4L2_PIX_FMT_SBGGR8 and
# V4L2_PIX_FMT_MJPEG then motion will by default use V4L2_PIX_FMT_MJPEG.
# Setting v4l2_palette to 1 forces motion to use V4L2_PIX_FMT_SBGGR8
# instead.
#
# Values :
# V4L2_PIX_FMT_SN9C10X : 0  'S910'
# V4L2_PIX_FMT_SBGGR8  : 1  'BA81'
# V4L2_PIX_FMT_MJPEG   : 2  'MJPEG'
# V4L2_PIX_FMT_JPEG    : 3  'JPEG'
# V4L2_PIX_FMT_RGB24   : 4  'RGB3'
# V4L2_PIX_FMT_UYVY    : 5  'UYVY'
# V4L2_PIX_FMT_YUYV    : 6  'YUYV'
# V4L2_PIX_FMT_YUV422P : 7  '422P'
# V4L2_PIX_FMT_YUV420  : 8  'YU12'
; v4l2_palette 8