> I think the default imp class should have a single Thread that just acts
as a proxy,
> buffering UsbIrps coming in and submitting them one-by-one
That means the function asyncSubmit() will not be blocked waiting for the
submission but still the submission thread will be blocked waiting for the
completion of an IRP. That means if IRPs are served in FIFO and there is a
delay in the submission of one of them, all the next IRPs should wait for
it. Is this the expected behavior or there is something I did not understand
?
Anyway, I found that asynchronous submission can be added to Libusb with
minor changes :D :D and I am working on it now :D :D and I will use the
default implementation.
I have another question. One parameter of Isochronous transfer is "Packet
Size" or "Number Of Packets". Can it simply be the maximum packet size of
the endpoint or it should be specified by the user of the library? and if it
should be specified by the user, Where is it in Javax.Usb ? In Libusb, it
is specified by the user of the library.
Thanks for your help
Bye
Islam Beltagy
On 8/9/07, Dan Streetman <[EMAIL PROTECTED]> wrote:
>
> On 8/6/07, Islam Beltagy <[EMAIL PROTECTED]> wrote:
> > Support asynchronous control submission: Don't know how to do it. Can
> you
> > please explain a little bit more about how to implement the Proxy Thread
> or
> > you can help me and implement it :$
>
> This should be relatively easy. In the common implementation there
> are interfaces for UsbPipe and UsbDevice lower-level implementations
> and "default" implementations of them (specifically,
> "DefaultUsbDeviceOsImp" and "DefaultUsbPipeOsImp", and
> "DefaultUsbControlPipeOsImp" as a control-pipe-special case in the
> com.ibm.jusb.os package). Each one provides "simple" implementations
> for the submit methods which all use asyncSubmit() as the only method
> that the os-specific imp needs to provide. This greatly simplifies
> the code in all platform-specific implementations, as they don't have
> to worry about sync submissions or byte[] vs. UsbIrp submissions.
> However it seems libusb only provides a sync function (weird...) so I
> think the best thing would be to put the change in the common
> implementation, to allow the platform imp to choose to implement
> either asyncSubmit or syncSubmit (instead of the current model,
> requiring asyncSubmit to be used).
>
> As far as the specifics on how to implement it, I think the default
> imp class should have a single Thread that just acts as a proxy,
> buffering UsbIrps coming in and submitting them one-by-one. Should be
> very easy. If you want to modify the common imp and send the change
> to me feel free, otherwise I will try to code it up in the next couple
> days and check it into CVS.
>
> > Support short packets: Don't know how to do it. If any one want to
> help,
> > all the code of IO submission is in the file transfer.c in the source
> code
> > of Libusb. I posted a request in Libusb mailing list to implement short
> > packets and I am waiting for reply
>
> This will be impossible to do correctly if libusb doesn't provide an
> interface to it. The short packet functionality is (supposed to be)
> handled at the USB Host Controller hardware level. However there is
> already code in the common implementation is to "fake" short packets,
> for just this case, of OSes that don't provide the functionality. So
> you don't have to worry about short packets at all. There is a
> parameter you have to set in the javax.usb.properties file that you
> provide, see the common implementation's example properties file:
>
> http://javax-usb.cvs.sourceforge.net/javax-usb/javax-usb-ri/docs/javax.usb.properties?revision=1.2&view=markup
>
> >
> > Thanks
> >
> > Bye
> >
> >
> >
> >
> > On 8/2/07, Dan Streetman <[EMAIL PROTECTED] > wrote:
> > > Ah, ok. I had forgotten about that code, it's been (or seems like) so
> > > long ago. Hopefully it will be easy to do the steps you listed to
> > > that existing implementation. Let me know how it goes!
> > >
> > > thanks.
> > >
> > > On 8/2/07, Islam Beltagy < [EMAIL PROTECTED] > wrote:
> > > >
> > /*************************************************************/
> > > > Get use of already implemented asynchronous IO
> > > > What is this?
> > > > Get use of already implemented Isochronous pipe.
> > > > What is this?
> > > >
> > /*************************************************************/
> > > > ok, what I mean is that the current implementation of Javax.Usbbased on
> > > > Libusb does not support asynchronous IO and Isochronous transfer,
> > despite
> > > > they are both implemented in Libusb
> > > >
> > > >
> > > >
> >
> -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by: Splunk Inc.
> > > > Still grepping through log files to find problems? Stop.
> > > > Now Search log events and configuration files using AJAX and a
> browser.
> > > > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > > > _______________________________________________
> > > > javax-usb-devel mailing list
> > > > javax-usb-devel@lists.sourceforge.net
> > > >
> > https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
> > > >
> > > >
> > >
> >
> >
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
javax-usb-devel mailing list
javax-usb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel