Quoting Dan Streetman <[EMAIL PROTECTED]>:
> If you put debugging higher than that, you might as well put it in the
> usbfs layer. In that layer, the file you want is
> "drivers/usb/core/devio.c" and the specific methods you want are
> "proc_submiturb" (which takes your buffer and sends it to
Here are a couple of USB monitors for Windows.
http://benoit.papillault.free.fr/usbsnoop/
http://www.hhdsoftware.com/download.html
The second one is a comercial product that you can try out for 30 days.
Fow actual boxes there are
http://www.catc.com/products/usbtracer_trainer.html but they don't l
Dmitri Kostioukov wrote:
Enclosed is a simplified version of my program that consistenly reproduces a
problem on my machine. If I do something wrong there and it could be easily
fixed, I'd be very surprised but very happy.
Is it my mailserver that removed the example, or did you not attach it?
//Ro
On Tue, 10 May 2005, Dmitri Kostioukov wrote:
>I just copied from the file and it was set to false at the time. Of course, to
>enable it, I do change it to "true". That bug was submitted by me and I did fix
>it myself but later updated from cvs. So there are no issues there.
Ah yes, thanks for c
Quoting Dan Streetman <[EMAIL PROTECTED]>:
>
> On Tue, 10 May 2005, Dmitri Kostioukov wrote:
>
> >This is what I have:
> >
> >
> >com.ibm.jusb.os.linux.LinuxUsbServices.JNI.tracing = false
> >com.ibm.jusb.os.linux.LinuxUsbServices.JNI.trace_level = 5
> >
> >Enabling urb tracing does not give me
On Tue, 10 May 2005, Dmitri Kostioukov wrote:
>This is what I have:
>
>
>com.ibm.jusb.os.linux.LinuxUsbServices.JNI.tracing = false
>com.ibm.jusb.os.linux.LinuxUsbServices.JNI.trace_level = 5
>
>Enabling urb tracing does not give me any more information.
Er, I'm not sure why you'd get ANY tracin
On Tue, 10 May 2005, [iso-8859-1] Roger Lindsjö wrote:
>What level were you using for the trace? Earlier it was possible to each
>byte[] as it was posted / received from the USB stack. Dan, is that
>still possible?
Yep, it is off by default though. In the 1.0.0 properties file, there is
a pr
On Tue, 10 May 2005, Dmitri Kostioukov wrote:
>> You could add debugging to the Linux kernel to see if it's getting the
>
>Can you tell me where to add those? I could simply work around this issue but I
>really want to get it fixed.
By far, the easiest way is the USB trace machine, of course.
Quoting Roger Lindsjö <[EMAIL PROTECTED]>:
> Would it be possible to show the code you use for communicating?
Enclosed is a simplified version of my program that consistenly reproduces a
problem on my machine. If I do something wrong there and it could be easily
fixed, I'd be very surprised but v
Dmitri Kostioukov wrote:
All devices are request/response. You send a request and get one or more 8 bytes
response buffers. In this specific case (8b) I'm requesting a status, which is
supposed to return 2 buffers. The first time around I only get 1 buffer back,
all successive request work fine. So
> Do you have the device's spec? Are you absolutely sure you should be
> getting the first response that you're missing?
All devices are request/response. You send a request and get one or more 8 bytes
response buffers. In this specific case (8b) I'm requesting a status, which is
supposed to ret
It does look from the trace like the in-direction is getting to the device
first. You could enable the "urb tracing" in the javax.usb.properties
file to get more detailed tracing about each URB, but I'm pretty sure
everything looks right from the javax.usb perspective.
To get a bus trace, you
Quoting Dan Streetman <[EMAIL PROTECTED]>:
>
> Your emailer is line-wrapping the JNI trace...can you resend as an
> attachment?
Attached
> I just want to verify with the JNI trace that the in-direction buffer is
> getting submitted before the out-direction buffer. It looked like, from
> th
Your emailer is line-wrapping the JNI trace...can you resend as an
attachment?
I just want to verify with the JNI trace that the in-direction buffer is
getting submitted before the out-direction buffer. It looked like, from
the JNI trace you sent, that the out-direction buffer was getting sen
Quoting Dan Streetman <[EMAIL PROTECTED]>:
>
> I have to assume the device is really not sending the first response you
> are expecting. Without knowing the device protocol, I have no idea why
> your device would skip that.
At first I assumed it was a problem with a device itself. But like I
I have to assume the device is really not sending the first response you
are expecting. Without knowing the device protocol, I have no idea why
your device would skip that.
If you can get a USB bus trace, you could check if the device was actually
sending the first response (and so show that
Quoting Dan Streetman <[EMAIL PROTECTED]>:
>
> If it's an interrupt pipe then you have to submit your buffer before you
> send the command down. Interrupt pipes are only polled when you pass a
I definitely do.
> buffer to the USB subsystem to use (i.e. to put poll data in). You need
> to s
If it's an interrupt pipe then you have to submit your buffer before you
send the command down. Interrupt pipes are only polled when you pass a
buffer to the USB subsystem to use (i.e. to put poll data in). You need
to submit several buffers so the USb subsystem always has a buffer to put
da
I've been trying to program x10 usb home automation interface and I always have
this problem - the first device response is always missing after my program
starts up. I see the same behavior with 3 different devices from 2 different
manufacturers. There's no special processing I do for the first re
19 matches
Mail list logo
