What the project's for:

All right. Firstly, this project aims to get the Creative Webcam Go (and variations, they all use the same chip) working. (Technically, it will work with any W9967CF or W9968CF based cam while commanded through USB)

That is, their video streaming abilities. Retrieving the pictures taken in detached mode may be the next step in this project, as it's not too far removed from the rest, but it's definately not an aim right now.
The microcontroller (Creative's) in there handles the buttons on the thing, and therefore capturing when the device is not being commanded by USB.

Basics on the cam:

Creative are not being helpful at all. They promised a driver some time back, but not only is there no driver, they're mumbling something about contracts when i ask the slightest detail about the thing. They might be right, but the fact stays that they're pains in the ass, and we cannot expect anything from them.


State of the driver:

Read the README.Developer file from the download you have.
Globally speaking, we have most of the necessary USB and video4linux functions implemented (save some of the actual data copying) but are stumped as to how exactly tell the camera to give us some image data (probably a mistake in the initialisation)
The current problem with the project is that the W9968 specs are not specific enough to enable us to initialise the cam and make it start sending image data.

I'ld type more, but i wanna get home right now. Now that i know how to bloody work scp (not - i just use ssh like telnet/rlogin) i'll update this page.

I'm currently considering (under, uh, strong suggestion:) putting up a little database of i-did-this-and-the-camera-did-that so that all ye list users can have a go at analysing sniffs and trying to initialise the cam. I'm not sure this is easy stuff; but it may be possible to give a few wrapping functions that makes that easy for non-usb experts like myself.

Here's a link to README.Developer (last uploaded on Thu 11 January 2018 (1:53am))

"At this point the driver is registered either with the USB than with the V4L."
should be `both' (...the USB and v4l subsystems)

"The disconnect is done via the w9967cf_destroy function, that deregister the driver from the v4l interface.
Note: This funcion is called from the USB subsystem when it detects you've unplugged the device.

Also, it says interface 1 means the speed ``1023 Mb/s''. This should say something like ``packet size 1023 bytes, roughtly equivalent to the practical maximum 10Mbits/s''.


There's three sniffs here: wgologs.tar.bz2. I'm writing a little intro how to read two of the thee of those.

I just added two more logs here: morelogs.tar.bz2. There is some interpretation and summary in both the files in it.

Sourceforge is removing FTP services - meaning i've moved what was there to the web space, but it's not all linked yet. I'm gonna see what exactly it is first.

Data from the logs:

I made a little PHP script (usable version here, source here) (hang on, i think i'll make this a C program, it's being annoying) that turns the usbsniff/usbsnoop (i keep forgetting what it's called) printed hex data into the binary data it represents and into a file.

For example, if you hand it:
00003302	24.29941760	 ff d8 ff c0 00 11 08 00 f0 01 40 03 01 22 00 02	
00003303	24.29942160	    0010:	
00003304	24.29950800	 11 01 03 11 01 ff dd 00 04 00 01 ff da 00 08 01	
00003305	24.29951200	    0020:	
00003306	24.29959920	 01 00 00 ff 00 f9 aa bf ff d0 f9 aa bf ff d1 f9	
00003307	24.29960320	    0030:	
It will hand back (in this case) a document with 48 bytes of binary data that you can save-as into a file.

I used it on lines 3301-5938 and 6047-7764 (appended, i'm assuming it's one block of data) of the `also isoc' file in the `morelogs' bz2. Will post the results, soemtime.soon.

It probably is pretty much be a jpeg, except xv and pixie complain there are no quantization tables - the error seems to come directly (it's literally the same) as the one from jpeglib, eg. produced by djpeg.

The way i'm understanding this, you need to set the quantization tables once (section 7.3.2 in the winbond specs suggests they're not set to anything in particular by default) and then you remember them and hand them to jpeglib when decoding each jpeg.

(I guess it's a little less data to transmit - except the quantization tables (luminance and chrominance, 64 bytes each) total 128 bytes, that's not a horrible optimisation.)

That is, when we get to using JPEG transfers, for now it's probably easier to use YUV transfers.


The project site: http://sourceforge.net/projects/winbond-webcam
This page: http://winbond-webcam.sourceforge.net/

Keatch's (Raffaele Spangaro's) site: (Did most of the developing) http://www.keatch.f2s.com/linux.html
David Gauchard site (wrote a log-to-code parser, i'm not exactly sure how useful it is. Also made some sniffs.): http://www.laas.fr/~gauchard/linux/sniff2mod/
Whizkid's winbond page (no clue, it was linked through david's site but it has some sniffs): http://trollcave.2y.net/linux/

[ Upload readme (for keatch) ]