Mohamed HAMZAOUI wrote:
Is this a bug on the libusb/WinUsb or a limitation ?
Yes, I consider it a bug. Others might not.
//Peter
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access
Pete Batard wrote:
We do have a maximum limit on the number of (fake) fds
Why is that?
Are there considerations (timing? something else?) related to asking
Windows for memory as needed vs. using the current fixed size internal
array?
Thanks
//Peter
Arne Pagel wrote:
As far as I understood libusb_get_config_descriptor gives my just
cached values, can I force this function to perform an actual read
from the Hardware?
No, but libusb_get_descriptor() will do a hardware access.
char buf[64];
libusb_get_descriptor(dev, LIBUSB_DT_CONFIG, 0x00,
therau2000 wrote:
libusb-1.0.dll is getting loaded by the interface class with the
following command:
MyLib libUSB = (MyLib) Native.loadLibrary(usb-1.0, MyLib.class);
I don't even know what programming language that is? :\
I need to unload libusb-1.0.dll to load another one.
Question:
therau2000 wrote:
libusb-1.0.dll is getting loaded by the interface class with the
following command:
MyLib libUSB = (MyLib) Native.loadLibrary(usb-1.0, MyLib.class);
I don't even know what programming language that is? :\
Fair enough. It is Java.
Ok. I googled:
David Grant wrote:
Rebooting is necessary for the add user to group change to take effect.
Once the user has been added to the group, it's very easy to upgrade
a running shell to use the new gid:
exec su ${USER}
(What it does is of course to *replace* the current shell with a new
shell, but
Stefano Di Martino wrote:
What now? My program has to run under windows.
If you want to communicate with the HID class interface then I
suggest to try out HIDAPI.
HIDAPI was created specifically to abstract OS-native HID class APIs
on Linux, Windows, and Mac OS X.
While the Windows-specific
Pete Batard wrote:
I don't believe there were suggestions in any direction so far, but
I think using more of HIDAPI in libusbx would be a logical extension.
Considering that libusbx is the lower level library here, theoretically,
the most logical thing would be for HIDAPI to rely on
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
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.
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?
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
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
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
g...@novadsp.com wrote:
Interfaces: 2
..
Interface Number: 0
Number of endpoints: 2
..
Interface Number: 1
Number of endpoints: 0
What I don't get is how to write to the second interface.
Using anything other than an index of 1 for libusb_claim_interface()
returns
Tim Roberts wrote:
You can write to the device's control endpoint
without claiming an interface at all.
I'm not sure this is true with WinUSB on Windows.
//Peter
--
Everyone hates slow websites. So do we.
Make your
Sean McBride wrote:
I just forked libusbx on github and tried to build it. README.git
says run either ./autogen.sh or ./bootstrap.sh but both result in:
libtoolize or glibtoolize was not found! Please install libtool.
autotools used to be part of Xcode, but was removed as of 4.3 (March
g...@novadsp.com wrote:
All I really need to do is send a few bytes of configuration data over
the control endpoint but can see no way of doing that with the Windows
stack in the way ..
Use bDeviceClass 0xff (vendor specific) and install the winusb kernel
driver using libwdi in any part of
Sean McBride wrote:
Note that autotools are requited _only_ for people using the GIT
version.
What is the difference? What is included with the released
version that is not included with git, and why?
The difference in this case is that the autotools have been run by
whoever created the
Sean McBride wrote:
Other than finding and installing 'libtoolize', is there another
way to build?
I guess not. Feel free to contribute something.
Where can I find Vitali's CMake support? I'd be interested to know
what state it's in...
Sean McBride wrote:
Homebrew [1] is a very nice tools for installing external tools on
Mac OS X.
$ brew install libtool
On Mac at least, that's now 3 dependencies:
- install Xcode
- install homebrew
- 'brew install' libtool
vs
- install Xcode
- install CMake
vs what is
Chuck Cook wrote:
From my point of view. I would like to see libusb-1.0 go through
another iteration or two.
Sounds like a great opportunity to get more involved. Go for it!
tests with baseline devices which exercise all functions of every API
If you've been using the API then this could
Lionel Debroux wrote:
The maintainer of libusb has proved, for two years, to be a roadblock on
the path of advancing the state of libusb and on making life easier for
users.
I think it would be fair of you to look closely at the repository
history before we discuss if and how I advanced the
Hi Bob,
Bob Lapique wrote:
the right place to seek help on basic Libusbx usage...
Sure, if you find no other resource to explain what you want to know.
If not, I'd be very pleased if someone could redirect me to some place
where the difference between the Linux and Windows implementations
Bob Lapique wrote:
What I want to do is to communicate with a home made board, based on a
Microchip PIC microcontroller (PIC18 or PIC32), with interrupt
transfers. I don't want anything special, just send and receive packets
to trigger measurements and get the results. But at the moment, if
Pete Batard wrote:
the error basically comes
from trying the following: _open(NUL, _O_WRONLY);
I don't understand why the fd integer is allocated using _open()
instead of allocating it in the library using a simple counter or so.
It seems that the fd is just a placeholder; no actual IO goes
I don't know how wise it is to mix the two different namespaces.
//Peter
--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics
David Grant wrote:
mass storage support?
I guess you already have the following in mind?
http://libusb.org/wiki/FAQ#CanIuselibusbtoopenafileonaUSBstoragedevice
//Peter
--
Live Security Virtual Conference
Exclusive
Kevyn-Alexandre Paré wrote:
I at least need to send 2 bytes to the FPGA to receive back a NAK
in case of a bad 2 first bytes. In case of a proper trame this will
send a ACK or data packet.
You can simplify your protocol significantly since USB transfers,
aside from isochronous, are a reliable
g...@novadsp.com wrote:
No good since there can be no data from device until you initiate a
transfer.
? err, no. My device might well start to write back down the pipe as
soon as it has been configured.
That would be a violation of the USB protocol.
What device controller are you
g...@novadsp.com wrote:
Once I have opened a device using LibUsbX, is there a
synchronization handle I can pend on whilst waiting for the
peripheral device to write back to the host?
The device is not allowed to transmit to the host before your
application requests data.
// open device etc.
Pete Batard wrote:
I have now pushed a patch that adds libusb0.sys and libusbK.sys
support there, for testing.
I look forward to some testing! Even if it comes at the cost of the
libusbK DLL it's still very nice that libusb-1.0 code can be used
with the libusb-win32 driver.
To fetch the
Andrea Oliveri wrote:
I run the same code under Fedora 17 and it's OK.
I think you get a warning in the kernel log.
When the application try to read data from the device under windows
i receive this error message:
libusbx: error [libusb_submit_bulk_transfer] unable to match endpoint to
Hans de Goede wrote:
The only way to fix this for certain is to add an atomic
detach-and-claim call to the kernel. I don't know if this is
worth it, though.
Having spend some time thinking about this, I believe it is worth
it, both to fix this race, as well as to fix the
Andrea Oliveri wrote:
how can i understand
Suggest show the code again, and since you are now getting to actual
data transfer please also include debug output.
https://libusb.org/wiki/debug mentions how to do this for libusb, but
the instructions work also for libusbx if you adjust the URL.
Hans de Goede wrote:
If the usbfs driver is found LIBUSB_ERROR_NOT_FOUND will be
returned to indicate no driver was detached.
What is the situation like for other platforms besides Linux, and
does the change also require documentation?
//Peter
Yves Arrouye wrote:
I was a bit surprised that the default installation obtained by cloning
(using git clone on the command line)
git://github.com/libusbx/libusbx.gitdid not include a configure
configure co are generated and included in release tarballs. Since
they are generated files they do
Pete Batard wrote:
you're going to earn yourself a ban.
That's confusing, but I guess you'll do as you like.
but working
with git does require more of you. I think that's a good thing
Please keep this bullshit about how git is going to save the world
I didn't write as verbosely as I
Pete Batard wrote:
Where did the issue become trying to convince Yves that using git
(or another VCS for that matter) was better for him?
I don't know how you came up with the idea that I tried to do that.
Fortunately it didn't seem like Yves interpreted what I wrote like
you did.
Kevyn-Alexandre Paré wrote:
Here's the code and output of my test. I'm trying to understand
what's going wrong! I mean that I'm expecting the callback function
cb_xfr from my bulk transfer to be called after
libusb_submit_transfer is called. I'm communicating to a FPGA
through a Cypress USB
Markus wrote:
I can't see a generally reliable way to get my hands on the HC
information while at the same time, being able to infer which
devices are connected (by means of libusb_get_bus_number() result).
Do I overlook something here?
Well the HC is not a USB device, so it does not fit
John Chen wrote:
Would you please show me how did you get bmRequestType to value 0xC2.
Please see the USB 2.0 spec 9.3.1 bmRequestType Table 9-2 page 248.
http://www.usb.org/developers/docs/usb_20_10.zip
//Peter
John Chen wrote:
I am using libusb-1.0.9, under windows 7
Just a note that the debug log you sent is from libusbx, so check
which DLL gets used if you intended something else.
I am also able to get serial # from one of our legacy app (written
with windows API)
Note that retrieving a string
Markus wrote:
my question is slightly off-topic since its affects a property of
USB that's presumably standardized. Nevertheless, I'm unable to
find any definite information on this:
Is it correct that the root hub of a host controller has always
address 255 on the given USB bus?
No, 255
Pete Batard wrote:
but it doesn't prevent you from retrieving root-hub descriptors.
The descriptors simply come from the OS's driver rather than from
an external device.
That makes sense.
Is it true also for Windows?
//Peter
Pete Batard wrote:
Is it true also for Windows?
The current code doesn't attempt to cache any descriptors for root hubs,
So the Windows USB stack does not provide root hub descriptors?
(If so that's perfectly fine, I'm just trying to understand how
Windows exposes the root hubs.)
Still,
the smaller timeout error and most importantly having the
user-specified timeout be a lower bound rather than an upper bound
is preferable.
//Peter
From ca77a1a541aaa3b2f0cbc4ea03e1eeca3dd5aa5a Mon Sep 17 00:00:00 2001
From: Peter Stuge pe...@stuge.se
Date: Tue, 10 Jul 2012 16:54:16 +0200
Subject: [PATCH
Kevyn-Alexandre Paré wrote:
Data never becomes available.
The application asks the device to send data, when the application
knows that data is supposed to be available in the device.
Agree, in my case I send data to an FPGA and I'm always expecting to
receive data from it. The
Kevyn-Alexandre Paré wrote:
3- In the callback I need to know what the FD is referring to and
take action, ex: data is ready to be read for the FD of bulk
transfer.
This is a misunderstanding of USB. Data never becomes available.
The application asks the device to send data, when the
Timotei Dolean wrote:
I'll look in the meantime into the alternative to the
select()-based method, maybe that will get it working.
Yes, it can't work before then.
//Peter
--
Live Security Virtual Conference
Exclusive
Hi Philip,
philip.jos...@microchip.com wrote:
the incentive to uncomplicated the user's experience has driven
many implementers to HID on Windows.
Yes, this is easy to understand. I think by far the best solution to
communicate with HID class devices manually is to use HIDAPI.
Even with our
philip.jos...@microchip.com wrote:
devices that do not have such descriptors will apparently still
require an INF file for install purposes.
Yes, that is true. At least the problem is going away in the future.
Having a single API and single library across platforms would
still provide the
Johannes Stezenbach wrote:
Doesn't Windows (WinUSB to be precise) return an error code
indicating the device was unplugged for the submitted transfers?
Can you provide a debug log? I assume you check for submit errors,
and I'm interested in seeing what happens to those later 13.
Thanks!
g...@novadsp.com wrote:
Assuming I need a user-mode interface to a custom USB Bulk class device:
1. Can I use Zadig to install a WinUSB driver for the VID/PID?
Yes, that's one of the things it is meant for. You can also use
libwdi in your own program, to do what zadig does, but in a more
Pete Batard wrote:
1. It sets the origin of the timestamps to the first libusb_init() call
issued by the application. The idea is to avoid getting an arbitrary origin
once we have toggleable logging, as it is currently set to the first debug
message ever issued, which isn't something an app
Yves Arrouye wrote:
How can I do that?
No solution AFAIK.
It does not help that the full command-line isn't displayed (how can I
see that instead of the fake command lines here, by the way)...
make V=1
rather not have to build twice and lipo everything together,
This does however work
Xiaofan Chen wrote:
I think the warning message is a bit miss-leading. If libusbx found
/, then it should probably warn against unrecognized device.
If Windows says that there is a 0:0 device when there is actually an
error, and if this case is indistinguishable from an OK device with
g...@novadsp.com wrote:
I've got a custom USB bulk device (Blackfin based with my own firmware
for what it's worth).
Fun! Did you already verify the USB part of the firmware, or is this
part of what you are doing right now?
I run xdev face:feed (our VID/PID) and all device info gets
Xiaofan Chen wrote:
ok pete i tryed it again,
got a bit of a different message, but still failed.
Also since you are using Cygwin which has its older libusb-1.0,
you may want to remove the older libusb-1.0 cygwin package
I've helped Dan with this a bit. The ubertooth package and a library
Pete Batard wrote:
On 2012.05.14 18:44, Peter Stuge wrote:
I don't think that should be neccessary. If replacing the driver does
not lead to a new libusb_device * for the device then I think it is a
bug if the device must be destroyed before accurate state is reported
by calls
Uri Lublin wrote:
Maybe the problem can be solved in the application.
I think that would be a workaround.
Likely I can unref it before driver installation, and find it again
after the installation.
It seems racy and unneccessary to me.
//Peter
Pete Batard wrote:
Right now, outside of not freeing the list (but in that case, expecting
an enum list to auto-update itself if after it has been generated IS
hotplug),
You seem to miss that the list is expected to be updated on call to
libusb_get_device_list() - noone has said anything
Pete Batard wrote:
The bug is that the Windows backend requires a libusb_device * to be
unref:ed before libusb_get_device_list() reports system changes,
while other backends do not have this limitation and it is documented
that libusb_get_device_list() does not have this limitation.
..
Pete Batard wrote:
if you want to dismiss the Windows backend as full of bugs
I never wrote that and I never hinted at that.
This email thread is about just one bug.
fixing this is likely to be a waste of time when we could spend it
on implementing the full hotplug.
..if you don't mind
Uri Lublin wrote:
Only if old backend api is UNSUPPORTED.
Hm. Shouldn't the check be done unconditionally - and for all
devices, ie. in every pass except perhaps HCD? Otherwise I think the
bug still bites when installing the previous driver after
unredirecting the device?
//Peter
Pete Batard wrote:
+int API_EXPORTED libusb_get_port_path(libusb_context *ctx, libusb_device
*dev, uint8_t* path, uint8_t path_len)
I think the proposed API could be simplified. There's a hard upper
limit on the path length (7 ports including the HC) so I would
suggest to drop the path_len
Pete Batard wrote:
On 2012.05.11 16:48, Peter Stuge wrote:
I think the proposed API could be simplified. There's a hard upper
limit on the path length (7 ports including the HC) so I would
suggest to drop the path_len input parameter and document that path
must be uint8_t [7] or longer
philip.jos...@microchip.com wrote:
Pete wrote:
an up to date device list, with all the USB properties
We currently do this in a layer above libusb
Can you tell us about how your users can use your layer? Ie. rough
details of the primitives and API offered?
Thanks!
//Peter
Pete Batard wrote:
From 971f4eb540a414020f4ac9a3cf7b64827cc69ae6 Mon Sep 17 00:00:00 2001
From: Peter Stuge pe...@stuge.se
Date: Wed, 2 May 2012 17:04:00 +
Subject: [PATCH] Core: Add a timestamping and thread ID to logging
---
Please clarify in the commit message what was changed since
://git.libusb.org/libusb-stuge.git x/version_rc_describe \
git cherry-pick FETCH_HEAD
//Peter
From 41a92270fe608351a610630be3369185ce3f35ed Mon Sep 17 00:00:00 2001
From: Peter Stuge pe...@stuge.se
Date: Thu, 19 Apr 2012 22:55:44 +0200
Subject: [PATCH] Core: Add struct libusb_version members rc
71 matches
Mail list logo
