Hi, 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. >> >> 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... 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 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. > Right now, since 2.x is still some time away, I'm kind in wait and see > mode: let libusb finalize their API, and then see how it works out in > practice. > That sounds reasonable, although I'm afraid it may be a very very long time before they actually do an official release. >>> What's our idea when we can get down to doing start >>> on the hot plug? > > Once we kickstart the 2.x branch, which means after we've pushed all the > changes and fixes we need for 1.x. I too want hotplug to happen in > libusbx as fast as it can, but there's only so much that can happen with > limited resources and a fairly full backlog. Ack. <snip> > Oh, and with regards to whether our next version will be 1.0.15 or > 1.0.17, if libusb wants to start a versioning pissing contest, with > their proposed 1.0.9 -> 1.0.16 jump, I think I'm gonna push for libusbx > to join in, as I find it rather amusing that a project that is anything > but RERO suddenly wants to compete on revision overtaking. Eh, no, please lets not go there. Lets just keep doing our own thing and let them be, other then taking what is useful from them and integrating that into libusx. And no, their version inflation thing is not useful :) > >> And do not worry, Peter wil sure drag the leg of Nathan >> and make sure the next libusb release to be a present >> for 2013 Christmas. :-) > > That's what worries me most right now. From a libusbx perspective, There > are some good changes in Nathan's proposal, so I wouldn't mind having > libusb releasing their 1.0.16 soon. 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. >> 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 ? Regards, Hans ------------------------------------------------------------------------------ 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
