Hi All,
I have been needing hotplug support on Windows for quite some time, so I
was eager to start testing this code. I've finally had the chance to, and I
think it's a great start (thanks Manuel for your groundwork!!). Here's my
preliminary findings:
1) The way that the hubs are enumerated is broken, with respect to the bus
number. Every hub is assigned its own bus number. This is fine if there
were only root hubs present but does not work otherwise.
2) The session id for a device is indiscriminately based on the calculated
hash of the device interface path in some places and the device instance ID
in other places, and the two values are never the same. This is therefore
broken.
3) Composite and HID devices are not enumerated correctly. The individual
interfaces of these devices are never discovered and assigned to the parent
device. These devices are discovered and presented in the device list, but
none of their interfaces are usable.
4) The hotplug thread only receives notifications for devices. This may be
fine in most cases, but it will not be when hubs or host controllers are
introduced or taken away.
With these discoveries, I forked the branch and started playing around.
I've made some significant progress in getting towards a fully working
solution. All of the above issues have been addressed, and the library is
now fully functional in most cases. There are a couple issues that need
remain to be addressed:
1) Since the hotplug thread can only receive notifications for registered
device interfaces, trouble arises with composite devices. If there is no
driver installed on any one of its interfaces, the interface path can't be
found when the device is enumerated. If the driver for any interface is
installed after the device has been enumerated, the hotplug thread will not
receive any notifications of this. The solution may be a just-in-time
approach where the interface path isn't searched for until the interface is
attempted to be used.
2) The bus numbering scheme is and always has been flaky in the Windows
backend. The bus number was previously derived from the position of the
host controller in the devinfo set. The order in which Windows will provide
the host controllers in this set is unknown, and add/removing host
controllers will obviously change this set. For example, let's say a system
has three host controllers, and let's say there are two libsusb contexts, A
and B. Two host controllers are functional, and one is missing a driver.
Context A is initialized and enumerates the hubs and find the two busses.
Now let's say the driver for the host controller is installed. Context B is
now initialized, and it enumerates the hubs and finds three busses. Windows
may present this host controller at index 0, 1, or 2 in the devinfo set.
Therefore the same devices on bus number 1 in context A may not be on the
same bus number in context B. The bus number is simply a book-keeping
thing, but it would be useful to ensure consistency. I have a potential
solution for this.
Chris
On Fri, Oct 11, 2013 at 7:58 PM, Manuel Francisco Naranjo <
notificati...@github.com> wrote:
> @photron <https://github.com/photron> You are right good catch, I will
> implement it that way then. I will look into clock code and re-use it's
> design pattern.
>
> —
> Reply to this email directly or view it on
> GitHub<https://github.com/libusbx/libusbx/issues/9#issuecomment-26189632>
> .
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> libusbx-devel mailing list
> libusbx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
>
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
