On 2012.07.19 15:06, Markus wrote:
> The Windows System Information reports the uPD720200 HC (driver
> 2.1.36, FW 4015) as PCI\VEN_1033&DEV_0194, and its root hub as
> NUSB3\ROOT_HUB30&VID_1033&PID_0194. The PID resolves to "Nucam Corp."
> in libusbx, which is plain wrong.
Well the thing is, the H
On Thu, 19 Jul 2012, Markus wrote:
> On Wed, 18 16:58 , Peter Stuge wrote:
> >
> > Why do you want to do this again? You mentioned bus bandwidth.
> > How would you like to use the bandwidth knowledge?
>
> Short answer:
>
> Because it helps to sort out data-rate problems that might occur
> due
On Wed, 18 16:58 , Peter Stuge wrote:
>
> Again, the root hub is not a USB device, but an implementation-specific
> part of the host controller. The root hub thus doesn't have USB VID/PID.
>
> If the HC is on a PCI bus then it will have a PCI VID/PID, but
> pretending that those are USB ids is a
Hi Alan,
it seems you did not follow the mails preceding the one you
replied to. This is all about libusbx providing certain information.
> > Right now, I can reliably tell which devices share a common bus.
> > However, currently it's only Windows that returns the correct
> > VID/PID for the root
On Wed, 18 16:58 , Peter Stuge wrote:
>
> Why do you want to do this again? You mentioned bus bandwidth.
> How would you like to use the bandwidth knowledge?
Short answer:
Because it helps to sort out data-rate problems that might occur
due to several high-bandwidth devices sharing a single bu
On 2012.07.16 19:06, Pete Batard wrote:
I have now logged an enhancement [1], currently targeted at 1.0.14, to
see if we can ensure that root hubs identified by libusbx always have
the same address, across all platforms.
As part of this enhancement, the attached patch will ensure that root
hub
On 2012.07.18 15:58, Peter Stuge wrote:
> Well the HC is not a USB device, so it does not fit into the
> libusb-1.0 API device model, which is (only) for USB devices.
This, I agree with, as long as we differentiate the HC part and the root
hub part.
> Again, the root hub is not a USB device
Thi
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 f
On Wed, 18 Jul 2012, Markus wrote:
> Hi Pete,
>
> thanks for you detailed reply.
>
> In the end it boils down to whether there is a chance to match
> devices found by libusbx to a certain host controller.
>
> I can't see a generally reliable way to get my hands on the HC
> information while at
Hi Pete,
thanks for you detailed reply.
In the end it boils down to whether there is a chance to match
devices found by libusbx to a certain host controller.
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
On 2012.07.17 22:13, Markus wrote:
> While information about the host controller itself is not accessible
> via libusbx, the root hub can be enumerated and queried for its
> VID/PID (which is identical to the HC make and model).
That latter part is only true on Windows I'm afraid...
In libusb and
Hi there,
nice to see that this topic raises an informed discussion.
Thanks a lot for the enlightenment.
As for your question:
> Is there a specific reason you would need root hubs to always have the
> same address on a single platform, or across multiple platforms?
For bandwidth sensitive ap
On Tue, 17 Jul 2012, Pete Batard wrote:
> >> 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
On 2012.07.17 01:46, Peter Stuge wrote:
> So the Windows USB stack does not provide root hub descriptors?
Not at the moment, no.
But if there's an USB 3.0 root hub driver out there that returns
descriptors, and someone wants them, it shouldn't be too difficult to
enable the feature.
> The more
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
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
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
-
>> 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
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
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 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
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
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
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
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
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
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,
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
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
29 matches
Mail list logo
