On Mon, 8 May 2000 [EMAIL PROTECTED] wrote: > The actual picture data starts appearing at about line 00001560.. Most cameras stick to pretty basic YUV datastreams; some optionally produce raw Bayer patterns. Look for frame markers, they should be there somehow to indicate: - if this packet is empty (because camera is too slow or does not stream data) - if this packet is first (or Nth) in the frame - what is in this frame (usually comes as a frame header, see CPiA) > 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. That's not right. Driver must switch to zero-payload interface if nobody receives the picture... why to waste bus bandwidth? > 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!) It is integrated. However video size code is poorly done and must be rewritten (by me, as soon as I can find several free hours). It will work as is, though, just picture is always aligned to left-top corner and extra (black) margins may be written. There are also two theoretical race conditions in driver unload (not dangerous). > 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. Some things -can- be farther from the truth, but not many :) WDM is a pure, rigid message-passing architecture, with lots of messages. V4L driver only deals with: - open/close - read/mmap - ioctl (specific to V4L only) In Windows many layers on top of the driver do image massaging. In Linux there is only the V4L client (except V4L2 which isn't here) > 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? Given that many WDM drivers cause blue screens ... no, thanks :) Seriously, you'd need a complete Windoze executable underneath, and it's not possible to force anyone to develop such emulation layer on Linux :) It won't work on different endianness or word size, for example, and on any non-Intel processor (PowerPC, MIPS, ARM etc.) > All I've seen coming out of my 3Com seem based on the > control and bulk_transfer packet types. Right, as far as I recall that's the only pipes provided. > 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. Most cameras provide uncompressed data. Actually, it's -hard- to do heavy-duty compression on a small camera DSP, so OEMs save on RAM, this is bad for compression too. > 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. Tables (color correction etc.) make up most of the driver size. > 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... I would expect some sort of LZ compression. No JPEG. > Windows decryption algorithms are not known for being especially > speedy, best to do everything possible not to clutter up the OS > processing time. But they could use MMX because Windows runs only on Intel... Dmitri --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
