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

[Xavion]

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

[Hans de Goede]

Hi,

Post by Xavion
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

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

[Jean-Francois Moine]

On Sun, 4 Mar 2012 11:25:19 +1100

Post by Xavion
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.

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

[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

[Hans de Goede]

Hi,

Post by 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.

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

Post by Xavion
`--> 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
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Jean-Francois Moine]

On Mon, 05 Mar 2012 09:33:18 +0100

Post by Hans de Goede
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 drive=

r,

Post by Hans de Goede
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.
=20
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 band=

width

Post by Hans de Goede
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?

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

[Hans de Goede]

Hi,

Post by Jean-Francois Moine
On Mon, 05 Mar 2012 09:33:18 +0100

Post by Hans de Goede
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.

Post by Jean-Francois Moine
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

[Jean-Francois Moine]

On Mon, 5 Mar 2012 08:58:30 +1100

Post by Xavion
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 =3D 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.

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

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

***@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.

[Hans de Goede]

Hi,

Post by 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!

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.

Post by Xavion
All I'm seeing today (at 90% and 75%
quality) is what look to be non-fatal errors, since Motion seems to
work correctly.
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?

Post by Xavion
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.

Post by Xavion
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.

Post by Xavion
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
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

[Xavion]

Hi Hans

Post by Hans de Goede

Post by Xavion
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.

Post by Hans de Goede

Post by Xavion
=C2=A0 =C2=A0 Mar =C2=A06 08:34:17 Desktop kernel: [ 7240.125167] gs=

pca_main: ISOC

Post by Hans de Goede

Post by Xavion
data error: [0] len=3D0, status=3D-18
...

Hmm, error -18 is EXDEV, which according to
-EXDEV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=

ISO transfer only partially completed

Post by Hans de Goede
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=

=C2=A0 =C2=A0(only set in iso_frame_desc[n].status, not

Post by Hans de Goede
urb->status)
I've seen those before, and I think we should simply ignore them rath=

er then

Post by Hans de Goede
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.

Post by Hans de Goede

Post by Xavion
In fairness to Motion, the default JPEG quality listed in its
configuration file is only 75%. =C2=A0I had upped this to 90% for cl=

arity,

Post by Hans de Goede

Post by Xavion
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

Post by Hans de Goede
JPEG's motion saves to disk if it detects motion. We're are talking a=

bout

Post by Hans de Goede
the compression quality of the JPEG's going over the USB wire, which =

is

Post by Hans de Goede
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.

Post by Hans de Goede

Post by Xavion
They also remained after I increased the three "vga_mode" ratios to =

"6

Post by Hans de Goede

Post by Xavion
/ 8" or changed Line 2093 of "sn9c20x.c" to "sd->quality =3D 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.

Post by Hans de Goede

Post by Xavion
Entering either of the following commands before starting Motion
didn't make any difference either.
=C2=A0 =C2=A0 export LD_PRELOAD=3D/usr/lib/libv4l/v4l1compat.so
=C2=A0 =C2=A0 export LD_PRELOAD=3D/usr/lib/libv4l/v4l2convert.so
The other thing I'm wondering about is how to force SXGA (1280x1024)
mode to be used. =C2=A0I've set the 'width' and 'height' variables i=

n the

Post by Hans de Goede

Post by Xavion
Motion configuration file correctly, but I still see the following
=C2=A0 =C2=A0 Mar =C2=A06 08:37:46 Desktop kernel: [ 7448.680301] gs=

pca_sn9c20x: Set

Post by Hans de Goede

Post by Xavion
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. =C2=A0Fr=

om the

Post by Hans de Goede

Post by Xavion
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 unpluggi=

ng and

Post by Hans de Goede
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 + OV76=
60)

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

[Theodore Kilgore]

Post by Xavion
Hi Hans

Post by Hans de Goede

Post by Xavion
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.

Post by Hans de Goede

Post by Xavion
    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
-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.

Post by Hans de Goede

Post by Xavion
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.

Post by Hans de Goede

Post by Xavion
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.

Post by Hans de Goede

Post by Xavion
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
    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.

Post by Xavion
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

Post by Xavion
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

[Xavion]

Hi Theodore

Post by Theodore Kilgore
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.

Post by Theodore Kilgore
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.

[Theodore Kilgore]

Post by Xavion
Hi Theodore

Post by Theodore Kilgore
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

Post by Xavion
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 ;-)

Post by Xavion
For the record, I've only got Motion set to capture four frames per
second at the moment.

Post by Theodore Kilgore
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

[Xavion]

Hi Theodore

Post by Theodore Kilgore

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.

Post by Theodore Kilgore
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 :-).

Post by Theodore Kilgore
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

[Jean-Francois Moine]

On Wed, 7 Mar 2012 09:59:28 +1100

Post by Xavion

Post by Hans de Goede

=C2=A0 =C2=A0 Mar =C2=A06 08:34:17 Desktop kernel: [ 7240.125167] =

gspca_main: ISOC

Post by Xavion

Post by Hans de Goede

data error: [0] len=3D0, status=3D-18
... =20

Hmm, error -18 is EXDEV, which according to
-EXDEV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=

ISO transfer only partially completed

Post by Xavion

Post by Hans de Goede
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=

=C2=A0 =C2=A0(only set in iso_frame_desc[n].status, not

Post by Xavion

Post by Hans de Goede
urb->status)
I've seen those before, and I think we should simply ignore them ra=

ther then

Post by Xavion

Post by Hans de Goede
log an error for them. Jean-Francois, what do you think? =20

=20
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.

Post by Xavion
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?
=20
`--> lsusb | grep Cam
Bus 001 Device 006: ID 0c45:627b Microdia PC Camera (SN9C201 + OV=

7660)

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

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

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

[Xavion]

Hi Jean-Francois

Post by Jean-Francois Moine
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

Post by Jean-Francois Moine
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