On Thursday 03 March 2005 6:25 am, Steve Hosgood wrote:
> On Wed, 2005-03-02 at 18:28, David Brownell wrote:
> > OK, then this looks weird. Can you see if this patch helps
> > at all? It shouldn't matter, but this test is more direct
> > and so it should catch cases where the hardware isn't quite
On Wed, 2005-03-02 at 18:28, David Brownell wrote:
> On Wednesday 16 February 2005 3:37 am, Steve Hosgood wrote:
> > Basically, David, your suggestion of "try small URBs" works! I am now
> > seeing 40 fps from my camera with URBs of 4K, 8K and 16K.
> OK, then this looks weird. Can you see if thi
On Wednesday 16 February 2005 3:37 am, Steve Hosgood wrote:
> Basically, David, your suggestion of "try small URBs" works! I am now
> seeing 40 fps from my camera with URBs of 4K, 8K and 16K.
>
> So I'd say that your first hypothesis below pans out nicely:
> ...
> > Now while that's normally a fin
On Thursday 17 February 2005 2:38 am, Steve Hosgood wrote:
> Does the USB hardware DMA-copy the contents of the incoming bulk packets
> straight into the URB at its correct offset?
Yes ... at least, USB host controllers that use DMA will do that. They
actually sit in a FIFO inside the controller
On Wed, 2005-02-16 at 19:37, David Brownell wrote:
> On Wednesday 16 February 2005 3:37 am, Steve Hosgood wrote:
> >
> > Basically, David, your suggestion of "try small URBs" works! I am now
> > seeing 40 fps from my camera with URBs of 4K, 8K and 16K.
>
> That tells me roughly where the bug is;
On Wednesday 16 February 2005 3:37 am, Steve Hosgood wrote:
>
> Basically, David, your suggestion of "try small URBs" works! I am now
> seeing 40 fps from my camera with URBs of 4K, 8K and 16K.
That tells me roughly where the bug is; thanks for helping find this!
I'll ask you test a patch later o
I hate top-posting, but I feel I must reply to David Brownell's latest
mail in that way so as to convey some good news first, then go into the
details.
Basically, David, your suggestion of "try small URBs" works! I am now
seeing 40 fps from my camera with URBs of 4K, 8K and 16K.
So I'd say that y
On Monday 14 February 2005 9:17 am, Steve Hosgood wrote:
>
> qh/cf49c100 dev2 hs ep2 42002202 4000 (8a00ad80* data1 nak0)
> da98f360 in len=0 4d00 urb d6189b00
> da98f480*in len=12288 b0008d80 urb d6189b00
> da98f420+in len=20480 5d80 urb d4452680
> da98f540 in
On Fri, 2005-02-11 at 17:37, David Brownell wrote:
> On Friday 11 February 2005 9:14 am, Steve Hosgood wrote:
> > On Fri, 2005-02-11 at 16:36, Alan Stern wrote:
> > > > Meanwhile, I ran my driver with detailed debugging of its own and what I
> > > > see is like this:
> > > >
> > > >
> > > > R
On Saturday 12 February 2005 2:03 pm, Alan Stern wrote:
> On Sat, 12 Feb 2005, Mark McClelland wrote:
>
> > What happens if the last URB submitted for the frame is only 20667
> > bytes, or whatever (frame_length % max_urb_size) is? I wonder if the
> > firmware just isn't able to pad-out partial
On Sat, 12 Feb 2005, Mark McClelland wrote:
> What happens if the last URB submitted for the frame is only 20667
> bytes, or whatever (frame_length % max_urb_size) is? I wonder if the
> firmware just isn't able to pad-out partial bulk packets reliably?
That's not how it works. The firmware nev
Steve Hosgood wrote:
Meanwhile, I ran my driver with detailed debugging of its own and what I
see is like this:
Receive 32768 bytes from camera: add it to the image-buffer
Resubmit URB
Receive 32768 bytes from camera: add it to the image-buffer
Resubmit URB
Receive 20667 bytes from camera: add
Mark McClelland wrote:
Unless I'm missing something, it looks like you're actually running it
at [EMAIL PROTECTED] FPS. From ovfx2.c:
#define SVGA_SPEED0x81/* speed: 0x80 = 40fps, 0x81 =
20fps, 0x82 = 13.3fps, 0x83 = 10fps ( >= 0x84 doesn't work) */
Well, I missed the obvious... I j
Steve Hosgood wrote:
On Wed, 2005-02-09 at 15:57, Mark McClelland wrote:
I just noticed this in one of the Windows driver files (2610.set):
;* Frame Rate = 40fps
HKR, %2610Vid800RGB2
On Fri, 11 Feb 2005, Steve Hosgood wrote:
> > Why do things get wedged instead of failing gracefully?
> >
>
> Well, assuming you hadn't intended to put a smiley on that, they get
> "wedged" because that's how I describe submitting a URB (8 of them
> actually) and none ever calls me back with dat
On Friday 11 February 2005 9:14 am, Steve Hosgood wrote:
> On Fri, 2005-02-11 at 16:36, Alan Stern wrote:
> > > Meanwhile, I ran my driver with detailed debugging of its own and what I
> > > see is like this:
> > >
> > >
> > > Receive 32768 bytes from camera: add it to the image-buffer
> > >
On Fri, 2005-02-11 at 16:36, Alan Stern wrote:
> > I get wedged as usual and I have to "kill -9" my viewer program from
> > elsewhere in order to rescue the situation.
>
> Why do things get wedged instead of failing gracefully?
>
Well, assuming you hadn't intended to put a smiley on that, they g
On Fri, 11 Feb 2005, Steve Hosgood wrote:
> OK, so I compiled a kernel with CONFIG_USB_DEBUG on, installed ehci_hcd
> with debug=2, and ran my camera driver modified to attempt 40 fps reads
> from the camera in 800x600 pixel mode, 8 bits per pixel.
>
> I get wedged as usual and I have to "kill -9
On Tue, 2005-02-08 at 15:32, Alan Stern wrote:
> A few details would help, such as the contents of /proc/bus/usb/devices
> and a system log with CONFIG_USB_DEBUG turned on.
>
Sorry for the delay. I had some hard disk problems.
OK, so I compiled a kernel with CONFIG_USB_DEBUG on, installed ehci_
On Wed, 2005-02-09 at 15:57, Mark McClelland wrote:
> I just noticed this in one of the Windows driver files (2610.set):
>
>
> ;* Frame Rate = 40fps
>
>
>
> HKR, %2610Vid800RGB24%\Fr
Steve Hosgood wrote:
I've written a driver for a USB camera which sends 1600x1200 or 800x600
images across a USB 2.0 bulk pipe. It works fine in 1600x1200 mode, but
if switched to 800x600 mode it only gets a couple of frames before it
wedges.
I took a look at the USB traffic with a (borrowed) USB a
On Wed, 2005-02-09 at 07:33, Greg KH wrote:
> On Tue, Feb 08, 2005 at 02:05:04PM +, Steve Hosgood wrote:
> >
> > Briefly:
> > I've written a driver for a USB camera which sends 1600x1200 or 800x600
> > images across a USB 2.0 bulk pipe. It works fine in 1600x1200 mode, but
> > if switched to 8
On Tue, Feb 08, 2005 at 02:05:04PM +, Steve Hosgood wrote:
>
> Briefly:
> I've written a driver for a USB camera which sends 1600x1200 or 800x600
> images across a USB 2.0 bulk pipe. It works fine in 1600x1200 mode, but
> if switched to 800x600 mode it only gets a couple of frames before it
>
On Tue, 2005-02-08 at 15:32, Alan Stern wrote:
> A few details would help, such as the contents of /proc/bus/usb/devices
> and a system log with CONFIG_USB_DEBUG turned on.
I'd better get busy building a custom kernel!
I can provide a listing of the contents of /proc/bus/usb/devices right
now th
On Tue, 8 Feb 2005, Steve Hosgood wrote:
> I've written a driver for a USB camera which sends 1600x1200 or 800x600
> images across a USB 2.0 bulk pipe. It works fine in 1600x1200 mode, but
> if switched to 800x600 mode it only gets a couple of frames before it
> wedges.
>
> I took a look at the U
25 matches
Mail list logo
