Thanks for the input.
I'll try all of your suggestions.
It sounds like you known WDM, but I'm a little unsure
a complete emulation layer would be needed. These
drivers after all deal with a very limited view of
the operating system, they are class drivers.
My C++ intuition says, alter the premise, and you alter
a class's reality.
Still, my primary task is the 3Com driver first,
anything else second. I'll focus on that.
If the IBM CT driver is a less than perfect model,
what would you suggest?
Or would learning the entire path from V4L to USB
be a 'growth' experience?
< always open to suggestions, jtw >
At 02:20 AM 5/8/00 -0700, you wrote:
>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
>
>
>
===================================================
John Willis
Microcomputer support
Internet Publishing Technologies Group
TXU Communications
icq : 47700679
web : www.txucom.com, www.johntwillis.com
email: [EMAIL PROTECTED]
Phone: 409.788.7523
FAX : 409.788.7566
this is my 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]
