therau2000 wrote:
> On Mon, 2012-10-29 at 01:15 +0100, Peter Stuge wrote:
>> Find out exactly how those commands get sent, and find a method to
>> send them which is outside the USB domain if possible, since that
>> will be both simpler for you to implement *and* will provide a
>> significantly bet
On Mon, Oct 29, 2012 at 9:17 AM, therau2000 wrote:
> On Mon, 2012-10-29 at 01:15 +0100, Peter Stuge wrote:
>
> Find out exactly how those commands get sent, and find a method to
> send them which is outside the USB domain if possible, since that
> will be both simpler for you to implement *and* wi
On Mon, 2012-10-29 at 09:06 +0800, Xiaofan Chen wrote:
> The other question is whether the "competing program" is really
> cross-platform or not.
The "competing program" is strictly 32-bit Windows. This was where I had
a major advantage: mine is written in Java 6 and runs on 32/64-bit Linux
(it r
On Mon, 2012-10-29 at 01:15 +0100, Peter Stuge wrote:
> Find out exactly how those commands get sent, and find a method to
> send them which is outside the USB domain if possible, since that
> will be both simpler for you to implement *and* will provide a
> significantly better user experience.
T
On Mon, Oct 29, 2012 at 7:51 AM, Xiaofan Chen wrote:
> Great you know what you want. It may be possible to achieve what you
> want with libwdi+libusbx, the problem is that 1 to 2 seconds maximum
> is not guaranteed if using libwdi to switch drivers, the process can take
> minutes.
The other quest
therau2000 wrote:
> > > In that case, will you please add "SCSI Pass Through" capability
> > > to libusbx?
> >
> > I won't, but maybe someone else will.
>
> Sorry, I thought you were making all decisions regarding where
> libusbx is going...
Pete Batard might tell you that I have no authority in
On Mon, Oct 29, 2012 at 4:52 AM, therau2000 wrote:
> That is not at all confusing to me: with "SCSI Pass Through" libusbx will
> likely allow me to communicate with my Device while maintaining its
> removable drive capabilities. It may also eliminate (I hope) the annoying
> side effect of detachin
On Mon, Oct 29, 2012 at 4:52 AM, therau2000 wrote:
> On Sun, 2012-10-28 at 20:57 +0100, Peter Stuge wrote:
>
> therau2000 wrote:
>> In that case, will you please add "SCSI Pass Through" capability
>> to libusbx?
>
> I won't, but maybe someone else will.
>
> Sorry, I thought you were making all dec
On Sun, 2012-10-28 at 16:57 -0400, Alan Stern wrote:
> On Sun, 28 Oct 2012, therau2000 wrote:
> > When program xusb fails to claim interface 0, it would seem possible to
> > "activate SCSI Pass Through". Further calls to libusb_bulk_transfer
> > could then be transparent to the application program
On Sun, 28 Oct 2012, therau2000 wrote:
> > Unfortunately libusbx does not automatically fall back to the
> > SCSI Pass Through.
>
> I do understand that libusbx does not automatically fall back to "SCSI
> Pass Through". But under Linux, when program xusb fails to claim
> interface 0, it does:
>
On Sun, 2012-10-28 at 20:57 +0100, Peter Stuge wrote:
> therau2000 wrote:
> > In that case, will you please add "SCSI Pass Through" capability
> > to libusbx?
>
> I won't, but maybe someone else will.
Sorry, I thought you were making all decisions regarding where libusbx
is going... Who do I ask
therau2000 wrote:
> > > You need to fork libusbx and create your own SCSI Pass Through
> > > backend by yourself if you really want to use libusbx.
> >
> > On the other hand libusbx already does this for HID class, so I
> > don't see why mass storage would be less worthy.
>
> In that case, will y
On Sun, 2012-10-28 at 20:24 +0100, Peter Stuge wrote:
> Xiaofan Chen wrote:
> > You need to fork libusbx and create your own SCSI Pass Through
> > backend by yourself if you really want to use libusbx.
>
> On the other hand libusbx already does this for HID class, so I don't
> see why mass storag
Xiaofan Chen wrote:
> You need to fork libusbx and create your own SCSI Pass Through
> backend by yourself if you really want to use libusbx.
On the other hand libusbx already does this for HID class, so I don't
see why mass storage would be less worthy.
therau2000 wrote:
> Before I tried to use
On Sun, 2012-10-28 at 21:12 +0800, Xiaofan Chen wrote:
> On Sun, Oct 28, 2012 at 8:09 PM, therau2000 wrote:
> > On Sun, 2012-10-28 at 11:51 +0800, Xiaofan Chen wrote:
> >
> > Given this scenario:
> > 1-uninstall any driver installed by zadig.exe;
> > 2-use example program xusb as a viable test pr
On Sun, Oct 28, 2012 at 8:09 PM, therau2000 wrote:
> On Sun, 2012-10-28 at 11:51 +0800, Xiaofan Chen wrote:
>
> Given this scenario:
> 1-uninstall any driver installed by zadig.exe;
> 2-use example program xusb as a viable test program;
> 3-use a USB memory stick for testing as it will show up as
On Sun, 2012-10-28 at 11:51 +0800, Xiaofan Chen wrote:
> You might take a look at this one if your device use raw
> SCSI Pass Through Interface.
>
> It seems to work under Linux and Windows. But I think it will not work
> under Mac OS X due to the fact that Mac OS X does not seem to support
> th
On Sun, Oct 28, 2012 at 8:58 AM, Xiaofan Chen wrote:
>
> Unfortunately libusbx is not the solution for your problem. If you have the
> control of the device firmware, you should make the device a USB composite
> device, with an interface to be the USB Mass Storage device and the other
> interface
On Sun, Oct 28, 2012 at 11:29 AM, therau2000 wrote:
> Under Mac OS X you will have problem as well but a codeless kext may
> help in order to use libusbx. In that case, the device will not function as
> a USB mass storage device. So you have a problem there as well.
> https://github.com/texane/st
On Sun, 2012-10-28 at 08:58 +0800, Xiaofan Chen wrote:
> On Sat, Oct 27, 2012 at 11:41 AM, therau2000 wrote:
> > libusbx is required because my Java Program is used on Linux and Mac OS X as
> > well. My prototype program does work without any modification under 64-bit
> > Linux. I have not tried
On Sat, Oct 27, 2012 at 11:41 AM, therau2000 wrote:
> libusbx is required because my Java Program is used on Linux and Mac OS X as
> well. My prototype program does work without any modification under 64-bit
> Linux. I have not tried it under Mac OS X yet due to lack of time.
Under Mac OS X you w
On Sat, 2012-10-27 at 04:46 +0200, Peter Stuge wrote:
> therau2000 wrote:
> > > > 2-More intensive testing showed
> > >
> > > What testing?
> >
> > My own testing; who else's?
>
> Of course, but how did you do it?
1-started a large file copy (over 100 MB) to Device's removable drive;
2-using "
On Sat, Oct 27, 2012 at 1:02 AM, Tim Roberts wrote:
> I don't believe any of the libusbx back-ends operate as a filter driver.
> However, I thought that the libusb-win32 COULD act as a filter.
> Am I wrong?
Yes libusb0.sys (libusb-win32 kernel driver) can act as a upper
filter and it works with l
Alan Stern wrote:
> > I still think the storage subsystem has your answer.
>
> Speaking as someone who knows practically nothing about the various
> APIs in Windows, the impression I get is that the "competing program"
> is using a "raw SCSI" interface.
Right, I think so too.
> Does Windows pro
On Sat, Oct 27, 2012 at 11:07 AM, Alan Stern wrote:
> Speaking as someone who knows practically nothing about the various
> APIs in Windows, the impression I get is that the "competing program"
> is using a "raw SCSI" interface. The analogous facility in Linux is
> provided by the sg (SCSI generi
On Sat, 27 Oct 2012, Peter Stuge wrote:
> > The sniffer output is from the "competing program" using default OS
> > driver USBSTOR. It contains BOTH types of communication and the
> > switch over is quite visible.
>
> Where would you say that it happens in the log?
>
> Also, do I understand corr
therau2000 wrote:
> > > 2-More intensive testing showed
> >
> > What testing?
>
> My own testing; who else's?
Of course, but how did you do it?
> > Let's try another approach: Tell us everything you know about the
> > device, and show some kind of capture of the non-storage communication.
>
>
On Sat, 2012-10-27 at 03:28 +0200, Peter Stuge wrote:
> > 2-More intensive testing showed
>
> What testing?
My own testing; who else's?
> Unless you see the "New device" bubble above the system tray I don't
> think there is any driver action going on.
I never said there was a device driver d
therau2000 wrote:
> > > There is visibly something similar to Linux's "detach_kernel_driver"
> >
> > How did you determine that?
>
> 2-More intensive testing showed
What testing?
> > > 1-how can we detach/re-attach the default USBSTOR driver under Windows?
> > > 2-how can we load and attach li
On Sat, 2012-10-27 at 02:57 +0200, Peter Stuge wrote:
> therau2000 wrote:
> > There is visibly something similar to Linux's "detach_kernel_driver"
> > followed by "claim_interface" followed by lets-do-business followed by a
> > "release_interface" followed by a "re-attach_kernel_driver" which t
therau2000 wrote:
> There is visibly something similar to Linux's "detach_kernel_driver"
> followed by "claim_interface" followed by lets-do-business followed by a
> "release_interface" followed by a "re-attach_kernel_driver" which then
> resumes normal removable drive operations.
How did you dete
The "competing program" definitely does not install anything. I double
checked that by dumping the full registry before and after it ran.
More intensive testing showed that while there is any transfer in
progress to/from the Device's removable drive, there is no possible
communication with the Dev
therau2000 wrote:
>
> 2-my Java Program is currently being used by well over 1600 people
> world-wide. Installing libusb-win32 driver is not an option because:
> a-it disables the default Windows removable-drive driver USBSTOR,
> therefore making it impossible to access recorded Videos/Photos;
Hello all,
here is the situation: a few months ago I wrote a Java Program to
configure a smart USB device by reading/writing a configuration file.
The Device (a spy camera commonly called the 808 #16) has an on-board
ARM processor and storage in the form of an SD card; its Firmware is
updated fre
34 matches
Mail list logo
