On Mon, Oct 29, 2012 at 9:17 AM, therau2000 therau2...@videotron.ca 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
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 better user
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
that
On Sun, Oct 28, 2012 at 8:09 PM, therau2000 therau2...@videotron.ca 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
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
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 you please add
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 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. I
On Mon, Oct 29, 2012 at 4:52 AM, therau2000 therau2...@videotron.ca 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
On Mon, Oct 29, 2012 at 4:52 AM, therau2000 therau2...@videotron.ca 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
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 this project.
On Sat, Oct 27, 2012 at 11:41 AM, therau2000 therau2...@videotron.ca 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.
On Sun, 2012-10-28 at 08:58 +0800, Xiaofan Chen wrote:
On Sat, Oct 27, 2012 at 11:41 AM, therau2000 therau2...@videotron.ca 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.
On Sun, Oct 28, 2012 at 11:29 AM, therau2000 therau2...@videotron.ca 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.
On Sun, Oct 28, 2012 at 8:58 AM, Xiaofan Chen xiaof...@gmail.com 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
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;
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
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 determine that?
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 then
resumes
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 libusb0 (.dll
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
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.
Find attached
On Sat, Oct 27, 2012 at 11:07 AM, Alan Stern st...@rowland.harvard.edu 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
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 provide this
On Sat, Oct 27, 2012 at 1:02 AM, Tim Roberts t...@probo.com 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
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 competing
26 matches
Mail list logo
