Hi, I'm new to the mail list and would like to contact people working on the 3Com USB camera driver for Linux. So far I have determined that USB Snoopy reads the traffic just fine, and I was thinking of running some simple B&W graphics images and capturing the traffic to try and work out the image data format. http://www.jps.net/~koma/ Example.. simple filled black box, outlined box, no box, primary colored boxes.. ect.. So far I've made a goofy log of the 3Com Camera while I unplugged it and plugged it back in: http://www.onslate.com/3com-pnp.log (about 2 kb) And a log of a single snapshot taken using the windows application: http://www.onslate.com/3com-snap.log (about 424 kb) The actual picture data starts appearing at about line 00001560.. note: as long as the camera is powered up, its periodically polled and generates traffic, even if an app is not loaded and using the camera. I made them accessible on my website.. please suggest if this is an inappropriate thing to do. The IBM CT camera driver looks like a good prototype source code for inserting the basic functions and creating a very rudimentary driver, I think its already integrated with the Video4Linux interface API ( a major plus!) Comments? Sage advice? Please contribute you opinions. Otherwise, the WinDriver example code for handling the Creative WebCam II model looks like a nice prototype. Other than the OS wrapper, the functions should be identical, right? Which also makes me wonder why there isn't a generic Windows driver loader for Linux USB that loads the driver and runs the code the same way.. as far as I understand, the Linux model is almost identical to DDK-WDM drivers, and that should mean the driver is equivalent to a userspace app that gets signals from the kernel for services.. it provides the service, and the kernel or the driver directs the results wherever. Wouldn't that speed up deployment of USB, if the enduser could use the exact same disk as provided by the manufacturer to 'hi-jack' Windows drivers, and use them in a generic USB driver loader with Linux? Am I incorrect in that USB is agnostic about OS platform and is still based on the fundamental four packet types? All I've seen coming out of my 3Com seem based on the control and bulk_transfer packet types. A small image generated a dump of 46,076 bytes, a larger one a dump of 124,032 bytes. Compressed or not, I don't know. When I test again, I'll record the image sizes in pixels, a non-compressed image ought to result in linear or 1/r^2 law differences in the byte sizes.. I'm not entirely sure, but an exact compression size is bound to be non-reproducable.. although, I noticed consistent 1e480 (124,023) byte transfers several times.. highly suggestive the image is not compressed.. or only RLE.. which is very doubtful. I'm very new to all of this, but my perspective says most Windows drivers will treat USB streams as Linux character type driver/devices.. mass storage units ought to be known by at least two devices, a raw, and a block device name. Technical details are sketchy at best, but the circuit board is stated on 3Com/Vista's Embedded project site as being a four layer circuit board with onboard algorithms, running at 300 mA.. and being incompatible with certain IBM thinkpads like the 560XL since that laptop does not support "highpower" USB devices, like the 3Com camera. Since the Windows WDM driver is only 37 kb, up from an earlier 23 kb. I can't imagine much sophisication in the transfered image format. After all its being delivered to VFW and TWAIN drivers in the main operating system.. even the Windows tools offer JPEG compression only during the "save" image portion of the program, at worst it must be a DIB, BMP, or simple transposition of bytes.. otherwise framerate would start to suffer... Windows decryption algorithms are not known for being especially speedy, best to do everything possible not to clutter up the OS processing time. Constructive critisism and guidance would be welcome. ================================================== John Willis Phone: 409.788.7523 Website: www.onslate.com Email: [EMAIL PROTECTED] This is my PGP digital finger print: C219 3E66 C570 9CFF B0C4 A947 01C5 A0B3 6173 34B9 ================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
