Hi,
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?
If this is the case, then
Sorry, I have to correct myself:
> If this is the case, then there are device addresses 0 to 126 +
> 255 (the root hub), correct?
As 0 is the setup address, it most probably is 0 to 127 + 255.
Regards,
/Markus
--
Live
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 strin
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,
Peter,
Here is what I have:
I am statically linked to libusb-1.0.lib ,
The legacy app is using _DeviceIoControl to get the serial number, the
error code returned from libusb_get_string_descriptor_ascii is 0xfffb,
return from libusb_error_name is "LIBUSB_ERROR_NOT_FOUND", that is a
Libusb s
Yes, I am doing a loop, but I only do libusb_open
and libusb_get_string_descriptor_ascii when VId & pID matches.:
if (desc->idProduct==pid && desc->idVendor==vid)
{
printf("Before call libusb_open\n");
r=libusb_open(dev,&m_handle );
printf("Before call libusb_get_string_descriptor_ascii\n");
//r=l
Ah, another Monday. And another great day for more baseless Windows
bashing/Windows inaccuracies, as spread by Peter...
On 2012.07.16 12:29, Peter Stuge wrote:
> 255 is an arbitrary value that Pete chose to assign to root hubs
> in the Windows backend, and is not a valid device address per the US
Hi John,
On 2012.07.16 06:28, John Chen wrote:
> I am using libusb-1.0.9, under windows 7, I already installed windows
> device driver and can see the information from Device Manager, I am also
> able to get serial # from one of our legacy app (written with windows
> API) , using libusb and libusb
[pbatard][1] opened [issue 36][2] on [libusbx/libusbx][3] July 16, 2012
> Harmonize the address of root hubs accross platforms
[1]: https://github.com/pbatard
[2]: https://github.com/libusbx/libusbx/issues/36 (Harmonize the address of
root hubs accross platforms)
[3]: https://github.co
On 2012.07.16 11:43, Markus wrote:
> Is it correct that the root hub of a host controller has always
> address 255 on the given USB bus?
To answer your question, no that is not the case, at least across
platforms. On Windows however root hubs will always have 255 as their
address.
I have now lo
With the link, it's even better, though the previous post to the list
should have provided it as well.
> I have now logged an enhancement [1]
[1] https://github.com/libusbx/libusbx/issues/36
/Pete
--
Live Security Virt
John Chen wrote:
> Peter,
> Yes, you are right, this is a custom device, Here is the legacy code
> to get the serial number
>
> if ( ::DeviceIoControl(m_hDeviceObject, IOCTL_EZUSB_GET_SERIAL_NUMBER,
> NULL, 0, serial, cb, &cbOut, NULL))
> ...
> do you know what I should do to map
> the DeviceIoC
On 2012.07.16 19:29, John Chen wrote:
> Yes, you are right, this is a custom device
OK.
> do you know what I should do to map
> the DeviceIoControl to libusb_control_transfer in this case?
The purpose of libusb/libusbx is to abstract OS dependent calls, so it
is not possible to mix OS spec
Tim,
Yes, I already installed the UMDF driver on windows, I do not know exactly
what libusb is trying to do here, I looked some of libusb's source code,
looks like it is using some of winusb api. from the legacy code (that
works), I noticed that it passes IOCTL_EZUSB_GET_SERIAL_NUMBER to windows
Peter,
Could you please elaborate on :
"you could uninstall the filter driver and then replace the WUDFRD with
WinUSB?"
what do I do on Linux?
Thanks.
John
On Mon, Jul 16, 2012 at 12:00 PM, Pete Batard wrote:
> On 2012.07.16 19:29, John Chen wrote:
> > Yes, you are right, this is a custom devi
On Mon, 16 Jul 2012, Pete Batard wrote:
> On 2012.07.16 11:43, Markus wrote:
> > Is it correct that the root hub of a host controller has always
> > address 255 on the given USB bus?
>
> To answer your question, no that is not the case, at least across
> platforms. On Windows however root hubs w
On 2012.07.16 20:04, John Chen wrote:
> Could you please elaborate on :
> "you could uninstall the filter driver and then replace the WUDFRD with
> WinUSB?"
>
> what do I do on Linux?
Well, if you're using WUDFRD and WinUSB, you are working on Windows, not
Linux.
Now, here's what I would invite
On 2012.07.16 18:38, Pete Batard wrote:
> Therefore your statement should really be that no USB device on Windows
> has a device address, insofar as libusb/libusbx defines it.
OK. Might as well pick on my inaccuracies in light of Alan's statement.
As Alan pointed out, as other OSes, Windows does
John Chen wrote:
>
> Yes, I already installed the UMDF driver on windows, I do not know
> exactly what libusb is trying to do here, I looked some of libusb's
> source code, looks like it is using some of winusb api. from the
> legacy code (that works), I noticed that it passes
> IOCTL_EZUSB_GET_S
On 2012.07.16 20:09, Alan Stern wrote:
> The device address is the actual value used on the USB bus to identify
> the device. It is a 7-bit number, and it can take on any value from 0
> to 127. However 0 is reserved for newly-connected devices; by the time
> a device has been enumerated its addre
Thanks Peter, it worked!! I got the serial number from
libusb_get_device_descriptor!! I have the following questions:
1) So I do not have to install Windows Driver for the devivce at all? what
is Zadig ?
2) I need to have the same code work on Linux, is there a equivalent Zadig
in Linux?
3) I ha
John Chen wrote:
> Thanks Peter, it worked!! I got the serial number from
> libusb_get_device_descriptor!! I have the following questions:
> 1) So I do not have to install Windows Driver for the devivce at all?
> what is Zadig ?
You installed a driver-based product without understanding what it
Peter,
One more thing,
althrough libusb_get_string_descriptor_ascii successfully get the serial #,
but it returns 0x000b (no zero) and const char* error =
libusb_error_name(r);
the error = 0x00013fe41e10 "**UNKNOWN**", no sure what it is.
Thanks.
John
On Mon, Jul 16, 2012 at 1:43 PM, Jo
Thanks so much, your guys are wonderful!
On Mon, Jul 16, 2012 at 1:51 PM, John Chen wrote:
> Peter,
> One more thing,
> althrough libusb_get_string_descriptor_ascii successfully get the serial #,
> but it returns 0x000b (no zero) and const char* error =
> libusb_error_name(r);
> the error
On Mon, 16 Jul 2012, Pete Batard wrote:
> On 2012.07.16 20:09, Alan Stern wrote:
> > The device address is the actual value used on the USB bus to identify
> > the device. It is a 7-bit number, and it can take on any value from 0
> > to 127. However 0 is reserved for newly-connected devices; by
On 2012.07.16 21:57, John Chen wrote:
> One more thing,
> althrough libusb_get_string_descriptor_ascii successfully get the
> serial #, but it returns 0x000b (no zero) and const char* error
> = libusb_error_name(r);
> the error = 0x00013fe41e10 "**UNKNOWN**", no sure wh
Hi,Gurus,
I need to convert a legacy app from win api calls to libusbx, most of the
legacy app is using DeviceIoControl , from libusbx docs, the I believe I
need to use libusb_control_transfer, but I am not sure how to change the
calls from DeviceIoControl calls to libusb_control_transfer as
the pa
On 2012.07.16 22:29, Alan Stern wrote:
> This means we lose one possible device address, since 1 will never be
> used as the address of an external device.
I was wondering about that as well, as I anticipate the same potential
issue if we switch to using 1 for root hubs on Windows.
> In practice
>> Does Windows guarantee that the DeviceAddress value is always > 0?
>
> The field is unsigned short, so yes.
Ah you meant > 0, not >= 0.
I already partially answered that, but my current assumption is that
Windows will never let a device that has a DeviceAddress of 0 be
accessible, since it w
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
-
On 2012.07.17 00:44, Peter Stuge wrote:
> Is it true also for Windows?
The current code doesn't attempt to cache any descriptors for root hubs,
which I think may be because the calls returned with an error when we
tried it.
However, I could very much see some of the vendor specific USB 3.0
dri
John Chen wrote:
>
> I need to convert a legacy app from win api calls to libusbx, most of
> the legacy app is using DeviceIoControl , from libusbx docs, the I
> believe I need to use libusb_control_transfer, but I am not sure how
> to change the calls from DeviceIoControl calls to
> libusb_control
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.)
> St
It seems to me that with the libusbx git version,
libusb-1.0.pc generated does not show the version
information. Strange.
$ cat libusb-1.0.pc
prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: libusbx-1.0
Description: C API for USB device access f
I have not touch anything like device driver before, do you have any good
book to recommend?
thx
On Mon, Jul 16, 2012 at 5:37 PM, Tim Roberts wrote:
> John Chen wrote:
>
>
> I need to convert a legacy app from win api calls to libusbx, most of the
> legacy app is using DeviceIoControl , from li
John Chen wrote:
> I have not touch anything like device driver before, do you have
> any good book to recommend?
One good resource is the USB 2.0 specification. Study chapters 5, 8,
and 9.
http://www.usb.org/developers/docs/usb_20_10.zip
//Peter
---
36 matches
Mail list logo
