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.
We:
- Know the main chip is the Winbond W9968CF (
specs are downloadable in the project download section)
, and never the 9967. The difference is the lack of microcontroller support
in the 9967, which right now doesn't matter as we're not touching that yet,
but just as a fact...
- Suspect the image sensor (the CMOS chip) is the Omnivision OV7620,
from psysical appearance (counting the number of pins on the sensor and comparing to a lot of image sensors' specs. Also, the OV7620's specs (also
in the download section) Looks suspiciously like the cam's specification and the windows driver's settings.
This is also not very useful information as most of the initialisation seems to be done by the W9968, and only when we fiddle with settings like contrast and whiteness (not yet; it helps getting image data to test this) is this actually useful. I figured out a little more than is in the OV7620/W9968 specs about the protocol used. That is, they put it a little confusingly. But all in due time.
- Also know there's a microcomander (often abbreviated uC, by the by) that
does the commanding of the thing when working in detached mode, and is actually
active in attached mode too: the way windows detects the button being pressed
is checking one of its registers (not to be confused with the winbond chip's
or the sensor's) about four times per second.
However, what i seem to think is the uC says `Creative' on it. Which sucks a
bit, but we don't need the thing, it's just what command (yes, it commands
the winbond chip about) the cam if it' not in USB-controlled mode.
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 Fri 19 April 2024 (8:40am))
Corrections/notes:
"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''.
Sniffs:
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.
Links:
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) ]