>>The process of capabilities discovery includes turning on isoc and the
>>saa711x, and this results in a bunch of non-valid data packets
David, you have load SAA7115 instead of the older SAA711X module right?
>>I suspect the problem has shifted to where the chip is being asked to send
>>more then the endpoint's actual packet size, or something in that area. Red
>>herring?
The packet size is this... #define USBVISION_MAX_ISOC_PACKET_SIZE 959 //
NT1003 Specs Document says 1023 .
It's true, the NT100x spec docs say 1023 is the max, but the snoopy logfiles
did say only 959 with any device which we had a snoppy log file from. Try
changing this to the 895 and see.
I don't think it's going to help. But we should try it and see.
>>As you did core_debug=36 (1<<2 (DBG_ISOC) + 1<<5 (DBG_FUNC)) you should see
>>it. If not, this is a bug :)
>>Do you have some windows usbsnoop dumps ? If so, we could analyze them to see
>>which alternate is selected and which packet size is selected.
The other devices have the similar packet size. Here is the URL. Looking
through memory lane right now.
http://sourceforge.net/forum/message.php?msg_id=3523937
Here is an example of some digging into the usb code.
Updated to kernel 2.6.14. Still get the -90 error. This is with
usbvision 0.9.3 dated November.
Looking in the code for urb.c it looks like all the ways of getting
that error have to do with the size of the transfer_buffer. The size being
passed is 30688 bytes (32*959). I notice the max size is 0x7FF if (dev->speed
== USB_SPEED_HIGH). This hardware only has USB1.1 so I am not sure if
that has anything to do with it.
The max limit on ISOC packet size being enforced by urb.c appears to
come from hub.c doing some query against the hub. In my case the "hub" is the
one on the VIA motherboard. It was working fine last year with a 2.4
kernel.
So as an experiment I just commented out the check in the
usb_submit_urb routine in urb.c. It worked! No more -90 errors and I can grab
frames with videodog. But I have no idea about the long term viability of this
quick fix. I don't have a set of 2.4 sources to compare with.
The device did work in kernel 2.4.x and seemed to break in 2.6.x.
Dwaine
----- Original Message ----
From: David Warman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Dwaine Garden <[EMAIL PROTECTED]>; Thierry MERLE <[EMAIL PROTECTED]>
Sent: Thursday, April 26, 2007 2:40:24 PM
Subject: Re: Belkin USBView II
Hi Thierry,
No, that bit of code is correct, so my problem is not there. I think it is
elsewhere entirely.
The process of capabilities discovery includes turning on isoc and the saa711x,
and this results in a bunch of non-valid data packets. I turned on camorama's
debug facility also, and it is complaining about VIDEOCGCAPS failing. IIRC,
that is a v4l1 ioctls request, and the current system I am building is v4l2. I
thought there was a compatibility layer, but it seems not to be working for
camorama. Or for vlc, which I just downloaded and looks for
v4l-vdev="/dev/video0", and complains "v4l demuxerls -al
error: cannot get capabilities (inval;id argument)".
I am looking for another imager program I can trust. gqcam connects but
displays all 0's for camera details, as if it also failed the caps collection
but decided to run with the empty struct instead of failing out. xawtv doesn't
run. I am about to test with ffmpeg + ffserver; tho that is a more complex
setup I trust ffmpeg more. I have the feeling that once I get connected
properly, the system will work.
As always , thanks for your continuing help on this project. It looks like when
I am done I may have a patch or two to submit.
Regards,
David Warman
On Apr 25, 2007, at 9:56 PM, Thierry MERLE wrote:
Hello David,
David Warman a écrit :
Implemented the changes mentioned, made a little bit of progress.
Now, running camorama with the modprobe usbvision debug flags set
(video_debug=4 core_debug=36), I get a stream of full size packets with bad
status (len=895, status=FFFFFFB5 - EOVERFLOW?), then a few null packets and
then about 42 empty packets before power off completes and camorama abandons
the attempt to start up. More than the dmesg buffer can hold, so I do not have
the start-up end of the trace.
Earlier, in the older v4l1 code, I noticed that the value from the
USBVISION_ALTER_REG register was used to compute the packet size for the isoch
urbs, but that the computation resulted in a packet size 64 bytes too large
(regValue needed -- to get the matching value) when checked against the max
packet size reported in the endpoint alternate selected. That particular line
of code is no longer in usbvision_init_isoc, and I am hunting down the
allocation code now. I suspect the problem has shifted to where the chip is
being asked to send more then the endpoint's actual packet size, or something
in that area. Red herring?
Any comments and/or pointers would be welcomed ....
The packet size is taken from the USB descriptor now.
In usbvision-core.c:2455 (usbvision_set_alternate):
if (dev->ifaceAlt != prev_alt) {
dev->isocPacketSize = dev->alt_max_pkt_size[dev->ifaceAlt];
PDEBUG(DBG_FUNC,"setting alternate %d with wMaxPacketSize=%u",
dev->ifaceAlt,dev->isocPacketSize);
As you did core_debug=36 (1<<2 (DBG_ISOC) + 1<<5 (DBG_FUNC)) you should see it.
If not, this is a bug :)
Do you have some windows usbsnoop dumps ? If so, we could analyze them to see
which alternate is selected and which packet size is selected.
Regards,
Davdid Warman
Cheers,
Thierry
David Warman
[EMAIL PROTECTED]_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
