Bug 16270

Created attachment 26899 [details]
 lspci -vvnn

Created attachment 26900 [details]
 lsusb

First-Bad-Commit : acef4a407ed6e0a9ed87a2747be592fe49e64bdd

For test purpose, may you get the last gspca tarball from my webpage
     http://moinejf.free.fr
and change the line 3282 of build/vc032x.c from
     (id->idProduct == 0x0892 || id->idProduct == 0x0896))
to
     id->idProduct == 0x0896)

(In reply to comment #4)
> For test purpose, may you get the last gspca tarball from my webpage
>      http://moinejf.free.fr
> and change the line 3282 of build/vc032x.c from
>      (id->idProduct == 0x0892 || id->idProduct == 0x0896))
> to
>      id->idProduct == 0x0896)

I'm not sure how to update the latest driver from the tarball. If it requires re-compiling the kernel, I'm not sure how to do that. 
I had reported a different bugs [ Bug 16077 ] and while testing mainline kernels I noticed this. 

How can i test the latest gspca.  

[@Jean-Francois Moine , on an unrelated note to this bug report , the built-in webcam is a 1.3Megapx cam , but the resolutionz i get are only 2 : qvga (320x240) and vga (640x480). Just wanted to mention , or shall i file a separate lower priority bug?]

(In reply to comment #5)
> [@Jean-Francois Moine , on an unrelated note to this bug report , the
> built-in
> webcam is a 1.3Megapx cam , but the resolutionz i get are only 2 : qvga
> (320x240) and vga (640x480). Just wanted to mention , or shall i file a
> separate lower priority bug?]

Never mind . Filed Bug 16290 . :)

To generate the gspca driver(s), you just need the kernel headers of your running kernel. As written in the README, unpack, cd in the new tree, do 'make' and 'make install' as root, and reboot (or remove/reload the modules gspca_vc032x and gspca_main from/to memory).

In the last version (2.9.44), I added some lacking delays. If the problem is still there, you may try to do the previous change (now at line 3283). It will reset you the driver as it was in kernel 2.6.33.

About greater resolutions, I know that the sensor of your webcam may do 1280x1024, but I have no USB trace. May you do it in MS-Windows? If yes, please, use a text sniffer as sniff-bin. I need only the trace of the start of streaming (activate the trace, run any viewer with a resolution 1280x1024 during 1 second or two, and stop the trace). Please, send directly the trace to me (moinejf@free.fr). Thank you.

(In reply to comment #7)
> To generate the gspca driver(s), you just need the kernel headers of your
> running kernel. As written in the README, unpack, cd in the new tree, do
> 'make'
> and 'make install' as root, and reboot (or remove/reload the modules
> gspca_vc032x and gspca_main from/to memory).

Yeah , i'v been trying that , but i keep getting following error during make :(

~/Download/gspca-2.9.44$ make
make -C /lib/modules/2.6.35-020635rc3-generic/build M=/home/vish/Download/gspca-2.9.44/build modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.35-020635rc3-generic'
  CC [M]  /home/vish/Download/gspca-2.9.44/build/benq.o
In file included from /home/vish/Download/gspca-2.9.44/build/benq.c:23:
/home/vish/Download/gspca-2.9.44/build/gspca.h:28:5: warning: "LINUX_VERSION_CODE" is not defined
/home/vish/Download/gspca-2.9.44/build/gspca.h:28:26: warning: "KERNEL_VERSION" is not defined
/home/vish/Download/gspca-2.9.44/build/gspca.h:28:40: error: missing binary operator before token "("
make[2]: *** [/home/vish/Download/gspca-2.9.44/build/benq.o] Error 1
make[1]: *** [_module_/home/vish/Download/gspca-2.9.44/build] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.35-020635rc3-generic'
make: *** [modules] Error 2


> 
> About greater resolutions, I know that the sensor of your webcam may do
> 1280x1024, but I have no USB trace. May you do it in MS-Windows? If yes,
> please, use a text sniffer as sniff-bin. I need only the trace of the start
> of
> streaming (activate the trace, run any viewer with a resolution 1280x1024
> during 1 second or two, and stop the trace). Please, send directly the trace
> to
> me (moinejf@free.fr). Thank you.

sent thanks.

I fixed the compilation error in gspca-2.9.45, thanks.

I also added a 1280x1024 mode, but it is the one for an other webcam. It may work... (from your traces, the ms-win driver knows only 300K pixels: the images are always 640x480).

(In reply to comment #9)
> I fixed the compilation error in gspca-2.9.45, thanks.
> 
Installs now , but still the problem of the green+purple image occurs for the two resolutions.320x240) and (640x480)

> I also added a 1280x1024 mode, but it is the one for an other webcam. It may
> work... (from your traces, the ms-win driver knows only 300K pixels: the
> images
> are always 640x480).
Replied on Bug 16290

(In reply to comment #10)
> Installs now , but still the problem of the green+purple image occurs for the
> two resolutions.320x240) and (640x480)

I cannot find the problem. May you send me an other ms-win trace? I need:
- start the trace
- run a viewer for 1 second
- stop it and re-run it again for one more second
- stop the trace.

Thanks.

Handled-By : Jean-Francois Moine <moinejf@free.fr>

Oh! Forgot to mention here. 
I'v sent the ms-win traces to Jean-Francois Moine and we are currently testing different versions of the driver. We are making progress on the driver but off the bug report here.

From testing, there is another regression that exists with the new driver:
- The driver was set with the webcam switched off , this means that every time I start applications ,like cheese, the application doesnt detect the webcam and i have to start the application again with 30secs of the last attempt. Otherwise the device will keep getting renamed from /dev/video0 to /dev/video1 ,and viceversa, and not be detected by applications. Probably is a powersave feature in the windows driver, but in Windows the logitech webcam app allows to reconnect which isnt possible in Linux. [this one is partially fixed with the new drivers we've been testing , where the problem occurs only at the first start.]

within* 30secs of the last attempt

I use again the bug tracking to alert the other people.

There are 2 identified problems:
- green-purple images which may appear randomly,
- after 30s inactivity, the webcam resets when writing to the bridge.

Vish, in the last gspca test version (2.10.5), there are:

- a full initialization at probe time.
  This may solve the problem of using the webcam more than 30s after system
  startup.

- a compilation option 'NO_POXXXX' which is currently undefined.
  When defining this option, the behaviour should be the same as in the kernel
  2.6.33. May you check it?

(In reply to comment #15)
> Vish, in the last gspca test version (2.10.5), there are:
> 
> - a full initialization at probe time.
>   This may solve the problem of using the webcam more than 30s after system
>   startup.
> 
> - a compilation option 'NO_POXXXX' which is currently undefined.
>   When defining this option, the behaviour should be the same as in the
>   kernel
>   2.6.33. May you check it?

I tried version (2.10.6)[make and make install] and i noticed that everything went back to how it was in kernel 2.6.33 .
And then uncommented  //#define NO_POXXXX 1  to   #define NO_POXXXX 1
And again installed it, this was back to the versions we were testing. It had the 30secs and the image problems

Sorry, I inverted the test NO_POXXXX.
May you confirm that when as in kernel 2.6.33, there are no green-purple nor 30s problems?
Also, when sometimes good with the POxxxx, had the images a better or lesser quality?

(In reply to comment #17)
> Sorry, I inverted the test NO_POXXXX.
> May you confirm that when as in kernel 2.6.33, there are no green-purple nor
> 30s problems?

Yup , with the version in kernel 2.6.33 , there is no green-purple or the 30s problem.

However, with the kernel .33 version there are other problems:
- Image quality is not as good as the new drivers
- I cannot use the 640x480 resolution, I get repeated:
gspca: ISOC data error: [109] len=1024, status=-71

which makes the camera pretty much unusable in that resolution and the log is rapidly filed with these errors[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/543485]

> Also, when sometimes good with the POxxxx, had the images a better or lesser
> quality?

The quality is better with the new version we were testing, [except for this green_purple problem and the 30s problem].

I believe that this better quality is due to the better auto-exposure control with the new driver. [Which i had mistaken and reported Bug 16077 as a drop in frame-rate.]

One solution could be[i'm just being subjective and not even sure if this is possible]:
- Use the image values from the kernel .33 [but we might still have the 640x480 ISOC data error]
- Plus add the new options we traced for [controlling the image frame-rate, exposure, auto-exposure on/off, backlight]

This might probably be an improvement over the older image , if we can control the exposure. [We can probably solve the 640x480 ISOC data errors in time for next release, if time is of the essence here.]

The problem is that the USB exchanges are completely different between the po3130 and the unknown poxxxx, and that I could not find any documentation about the sensor and the bridge.

In the new gspca test tarball (2.10.7), I let back the probe exchanges which were bypassed for your webcam. This may initialize some registers. May you check it?

(In reply to comment #19)
> 
> In the new gspca test tarball (2.10.7), I let back the probe exchanges which
> were bypassed for your webcam. This may initialize some registers. May you
> check it?

Hi,
Tested the latest version, it still has the 30secs problem.

Regarding the image , the green-purple is back to being consistently a problem in one resolution[similar to 2.9.51].
 One resolution constantly has the problem while in the other the image is good [and the 160x120 is still similar to the images i had sent you earlier]

In the new 2.10.8, I did as you suggested: init as in kernel .33 and new controls.
May you check it?

For information, in your previous message, you said that one resolution was good. Was it always the first (or the next) activated one, or was it at random?

Any news?

(In reply to comment #22)
> Any news?

Hmm, seems something went wrong with the bugzilla mail daemon, I did not receive your earlier mail, on 08-28  , i only got the mail now with both your comments at once... 
Will check today! :)

(In reply to comment #21)
> For information, in your previous message, you said that one resolution was
> good. Was it always the first (or the next) activated one, or was it at
> random?

It was mostly random , i couldnt find a pattern for that.


> In the new 2.10.8, I did as you suggested: init as in kernel .33 and new
> controls.
> May you check it?
> 

Tested with gspca-2.10.17 , which might be the same as gspca-2.10.8 , i suppose..

It works better now, the start with older kernel hasnt caused much image problems. 
Havent noticed the green+purple image problem or the 30sec problem.

Whats Improved over kernel .33 driver:
 - The 640x480 works fine now, very much rare ISOC errors now which i had mentioned in comment #18  and its more usable. [320x240 never had this problem so its good too.]
 - The new additions Auto-exposure, Exposure, Gain controls work. Which allows better image quality when i control with v4l2ucp.

Whats NOT working from kernel .33 driver:
 - Brightness, Contrast, Saturation controls in v4l2ucp [direct driver controls] do not work. While i can make those changes using the cheese software.

Whats NOT working:
 - The new larger resolution, 1280x1024 does not work still, it gives a cut image and stutters two frames.

Whats behaving weird:
 - If I switch resolutions from 640x480 <-> 320x240, the camera /always/ starts with auto-exposure ON. The new additions Exposure, Gain controls work only if i toggle the Auto-exposure checkbox once and deactivate the auto-exposure again.
This is also a problem when changing the effects in Cheese , since it starts the webcam once again. So it seems like not the changing resolutions , but rather that the webcam starts with auto-exposure ON always.

While this version has some problems its surely an improvement over the drivers in .33 and .34. [mainly because .34 driver had too many other problems ;-)].