Quoting Stefan Nilsen <[EMAIL PROTECTED]>:
> How do I get the callback to cbTbl.processData to be called?
/* No signals - we just got new data in dp queue */
if (uvd->flags & FLAGS_NO_DECODING)
usbvideo_CollectRawData(uvd, frame);
else if (VALID_CALLBACK(uvd, processData))
GET_CALLBACK(uvd, processData)(uvd, frame);
This means that if you have FLAGS_NO_DECODING set then a built-in
raw data collection procedure is called instead.
> I've put some debug printout in that fuction but I dont see anything in the
> log. I load the driver using "insmod webcamgodrv.o debug=3"
You probably use usbvideo_GetFrame() as getFrame callback (handler).
I think this should be usable for most applications, unless the device
requires some very special handling.
> The camera separates images using one or more 0 length frames. It doesn't
> have any "magic" number that indicates the start of a new image. Can usbvideo
> handle that case?
Yes, but not in "right" way. I discussed that off-list recently.
usbvideo, as it is now, has only one ring queue for the collected data,
and it has no attributes attached to any place of that queue (which
could tell that a new transfer starts here or something.) To correctly
implement what you need requires a message queue instead of ring queue.
However this is irrelevant to your problem because (for now) you just
need to insert your own "magic" marker (which is unlikely to appear
on its own in the valid data stream). Then the decoding routine will
be looking for that marker (as ibmcam does), and you know where each
transfer (or frame) starts. Make change in usbvideo_IsocIrq() to do that.
When usbvideo gets extended to support block-oriented transfers then
this workaround will be unnecessary. But I plan to keep the ring queue
around anyway because it is the fastest way for streaming devices,
which do not care about USB framing.
Thanks,
Dmitri
--
"...[Linux's] capacity to talk via any medium except smoke signals."
(By Dr. Greg Wettstein, Roger Maris Cancer Center)
PGP signature
