On Mon, Feb 11, 2013 at 10:25 PM, Hans de Goede <hdego...@redhat.com> wrote: > On 02/10/2013 04:05 AM, Pete Batard wrote: >>>> Has anyone actually had a peek? >>> >>> I have asked the other admins to take a look at >>> Nathan's proposal. Hans has given one feedback. > > I've taken a quick look at Nathan's proposal, and I plan to do a > (personal) libusbx git tree with Nathan's hotplug code merged into it > sometime this week.
That would be nice. I am still working with Nathan to debug the issues under Mac OS X. The latest libusb-darwin git tree failed on Linux as well (regression). I think Nathan should be able to sort out the issue pretty soon. He is quite quick to respond with my suggestion about the hotplug example. I feel a bit sorry for Nathan who has quite some good ideas and more dedication to libusb than Peter yet his efforts will probably be hindered by Peter... >>> I think the hotplug API proposed there is not complete >>> and I am sure Pete will have some different ideas >>> about the API. libusbx and libusb will probably diverge >>> on the Hotplug API. >> >> That's the way I see it as well. I can't help but feel concerned that >> once again we have an API that originated straight from POSIX >> environments, and that hasn't bothered much in trying to at least >> outline what it's gonna mean for Windows. I kind of remember seeing at >> least one area where I had to wonder how Windows was going to make the >> proposed scheme work. > > Hmm, I don't see anything inherently Posixy in their API proposal, it > is a straight-forward API where you register a callback, and then have > that called on events. > > They don't even have the event loop pumping problem we have with the > async API, since libusb will spawn a thread itself for the hotplug > stuff, so API users should always be prepared for the callback to run > from another thread (which one could argue is a downside of their API > design for Linux, since most apps there will simple want a single > select driven event loop), but I don't see this as a problem for > implementing it under Windows. > > They also have seem very simple device filtering in there, but again > nothing which should be a problem under Windows I think, one can > filter on vendor-id, device-id and device-class. Yes device class, > utterly useless if you ask me, but it is there... Under Windows, I think matching device GUID would be nice, just as what libusbK is doing. I feel the device filtering method proposed by Nathan is good for many use cases but not that complete. I'd like to have a customer matching function if possible. Reference: libusbK's Windows centric implementation of hotplug. http://libusbk.sourceforge.net/UsbK3/group__hotk.html http://libusbk.sourceforge.net/UsbK3/hot-plug-monitor_8c-example.html Its patten match is like this, of course it is Windows centric but this may provide you the ideas about Windows. http://libusbk.sourceforge.net/UsbK3/struct_k_l_s_t___p_a_t_t_e_r_n___m_a_t_c_h.html I think vid/pid/class matching in Nathan's proposal is good but not complete. > There may be some gotcha's when you start using libwdi to replace the > native windows driver with winusb / libusb0 / libusbk while an app > using the hotplug stuff is open, but that is unrelated to the API, that > is just tricky in general. I do not think that is the way to go. I do not quite like the idea of adding libwdi into libusbx. Take note driver switching is time consuming and may lead to quite bad user experiences if done in an libusbx based application. > I would appreciate your input on any potential Windows issues with > Nathan's current API proposal here: > http://www.cs.unm.edu/~hjelmn/libusb_hotplug_api_alt4/group__hotplug.html > > Then we can try to get them to change the API before it is too late. Yes I will encourage the libusbx users here to look at that API and give feedbacks. > Agreed, I would not mind seeing a libusb-1.0.16 either, but I too am > afraid it may take a long long time before we get one. So I think we > should not wait, lets just do a 1.0.15 when *we* are ready, and if shortly > after that they do a 1.0.16, we can take whatever is good from there and > do our own 1.0.16 then. > >> I'm also thinking we could use the LIBUSB_CAPABILITY thing for HID, >> since not all platforms have it. We may also extend that for topology, >> since that's missing from *BSD, and it doesn't look like we're gonna get >> much help for it there. > > Well we already have libusb_has_capability, so we can already start using > that, the only challenge will be keeping the enum libusb_capability abi > compat with what "the other side" is doing. As said I don't think we should > wait for 1.0.16, so if you want to add new capabilities to the enum, lets > do that. But we should then (at-least for the 1.0.x series) coordinate > with them on this. I'm hereby volunteering to do that coordination. I agree that we should not wait. 1.0.15 only has one major issue #69 left. I'd like to get it sorted out and then get 1.0.15 out of the door. https://github.com/libusbx/libusbx/issues/69 As for WinCE integration clean-up, it can be post 1.0.15 release. It is very good that you can act as the coordinator. I agree it is good to be API compatible with libusb-1.0.x for libusbx-1.0.x. V2.x can be API incompatible and with strong libusbx branding. >>> That being said, libusbx is a independent project from >>> libusb. Down the road, the API will diverge and I >>> support Pete's vision to change the header file and >>> library name to libusbx to differentiate from libusb >>> post 2.0 release (at the same time, Hans wanted to >>> maintain an API compatible 1.x series if that is >>> possible, see milestone 1.0.16 which is to be compatible >>> with 2.1 but with no API breakage). >> >> Yeah, I'm kind of hoping that after 1.0.15/17/whatever Hans will take >> over 1.0.x, and I can get going with 2.x. But it looks like both Hans >> and I are quite busy, so we'll have to see how it works out in practice. > > Actually, I've had looking into the whole hotplug situation on my > TODO list for $dayjob for a couple of weeks now, but other stuff got > in the way. I've a good hope of actually doing a libusbx tree with > Nathan's work added this week. > > Note I'm not claiming that that is Nathan's hotyplug work is the best way > forward, we may very well want to do something different > for libusbx-2.x. But we should seriously consider using it for > libusbx-1.0.x to allow our users to easily switch between the 2. > > I know how you (Pete) feel about this, so maybe after 1.0.15 it is > time for me to take over the 1.0.x series, and you can then > focus on 2.x ? Great idea. I fully support this. I have updated the roadmap here. https://github.com/libusbx/libusbx/issues/milestones 1) rename V3.0 as V2.2 2) rename V31. as V2.3 3) created milestone 1.0.16 and 1.0.17 Please feel free to change them. -- Xiaofan ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
