This is a quick and dirty reverse engineer of the ST microelectronics STV0674 *NOTE* this is *not* the STV0680 that is a completely separate device! the current web page for this device is http://www.vvl.co.uk/products/co-processors/674/674.htm As is becoming increasingly more common the chip vendors are being right pains in the bum and forcing me to reverse engineer their protocols from snoops rather than giving me the data sheet. If your in a position to get the datasheet for this product please please do improve this driver! So far this driver has only been tested on a l'espion xtra other cameras may need more tweaks. The device has a single interface with several alternate configs, alternate 1 has 3 endpoints :bulk in, bulk out and an interrupt. The driver selects alternate one and uses the bulk in endpoint for data. Several control transactions are used to control the data available on the bulk in pipe. Most transactions are associated with an image number this is a 4 byte MSB value which appears to start at *2* ie the first image is 00 00 00 02. The image "header" is a block of data which is not associated with the jpeg data at all but contains several pieces of information, some important bits are: - image length (bytes 0x47(MSB) and 0x48) - x size (0x49 (MSB) 0x4a) - y size (0x4b (MSB) 0x4c Control transactions -------------------- Ping ---- I assume this transaction is a "ping" as the windows driver seems to perform this transaction like a nervous twitch, its done all over for no good reason I can see, always with the same result The host reads a control transaction with 1 byte URB bRequest = 0x80 wValue=0x0000 wIndex=0x0000 wLength=0x0001 the returned URB: byte 0 is always 0x00 Get header ---------- This obtains a block of data which contains the image "header" The host writes a control transaction with 6 byte buffer bRequest = 0x0A wValue=0x0000 wIndex=0x0000 wLength=0x0006 the data buffer has: bytes 0-3 are image number bytes 4-5 are length (MSB) this is always 0x56 in the doze driver the client may then read the "length" bytes from the bulk in pipe Set Image Number ---------------- I believe this is used to select the image for some transactions that don't explicitly set the image number themselves This and the following are done immediately before each image download The host writes a control transaction with 4 byte buffer bRequest = 0x03 wValue=0x0000 wIndex=0x0000 wLength=0x0004 the data buffer has: bytes 0-3 are image number Unknown ------- This *always* follows the above The host reads a control transaction with 2 byte buffer bRequest = 0x86 wValue=0x0000 wIndex=0x0000 wLength=0x0004 the data buffer has: byte 0 is always 0x03 byte 0 is always 0x01 Image header read ----------------- This is performed before each image is read, its just a repeat of the header obtained with the other request but its useful here for getting the image size, the doze driver always does it here and if you don't it breaks ;-) The host writes a control transaction with 8 byte buffer bRequest = 0x05 wValue=0x00ff wIndex=0x0000 wLength=0x0008 the written URB contains: bytes 0-3 are image number bytes 4-7 are the length of data to read (always 0x200 for the header read) 0x200 bytes are then read from the bulk in pipe, this seems to be an extended header? Image read ---------- This is identical to the image header read above except the wValue has changed from 0xff to 0x08. The windows driver writes a series of these commands asking for 0x1000 bytes of data a time, larger seems to fail... so reading blocks of 0x1000 and a fragment of smaller seems to be the best way to go. The host writes a control transaction with 8 byte buffer bRequest = 0x05 wValue=0x0008 wIndex=0x0000 wLength=0x0008 the written URB contains: bytes 0-3 are image number bytes 4-7 are the length of data to read (0x1000 or less) read close ---------- This transaction is performed at the end of the image read. The host writes a control transaction with 4 byte buffer bRequest = 0x09 wValue=0x0000 wIndex=0x0000 wLength=0x0004 the data buffer has: bytes 0-3 are image number