On Mon, May 7, 2012 at 6:02 AM, Pete Batard <p...@akeo.ie> wrote: > On 6 May 2012 15:32, Xiaofan Chen <xiaof...@gmail.com> wrote: >> I think maybe it is a good idea to extend the discussion >> to a bigger group now that libusbx-devel is open to the public. > > Which is also what I want. But I also want to make sure that both > sides are represented as they should and I don't see that happening > right now without negatively impacting our current uncompleted work. > > A lot of the discussion we had last time revolved on people simply > trying to grasp what the various issues were, so that instead of > having a kneejerk reaction "separate process = too much complexity", > they instead could base their decision on understanding: > 1. The issues we were trying to address (which includes more than the > matters that concerns you with regards to getting an enumeration that > is similar to libusbK's), and how they relate with other features we > plan to integrate. > 2. The pros and cons of addressing these issues in a specific way. > > >From the last discussion, it's pretty clear to me that outside of a > proposal, as well as an existing hotplug, it may be quite difficult > for many to understand the pros and cons of each approach. Therefore, > I am weary of any "discussion" that is going to leave very important > aspects aside and provide people with a less than complete picture. > > This is pretty much what I proposed last time around: address these > various items in sequence, with this one coming after hotplug, so that > everybody can get a more complete picture to make an educated > decision. And I don't remember much of anyone voicing concerns about > doing it this way. So I'm a bit puzzled about what looks to me as an > attempt to preempt a decision for a feature that, because it pertains > to enum, for which hotplug will be a game changer, is logically better > left to discuss for after we have hotplug. >
You read too much in my email, I have no intention to preempt a decision. In fact, I told Travis it is not possible to change too much the Window enumeration codes with you in the rein of the Windows codes. So I actually want to get the simple VID/PID filter done first which you agree in your first reply that "as Segher's suggest is a no brainer, and, IIRC, we used to have something similar in the 0.1 API, so I'm fine with that". BTW, there is nothing like that in the 0.1 API. And I have another idea is to see whether it is possible to filter using driver attached. OpenBSD/NetBSD anyway only support ugen driver (similarly for FreeBSD's libusb wrapper but the kernel there is more intelligent and can expose ugen along uhid for generic HID device). And it is anyway good to know the driver assigned and see what its capability of libusb support as suggested by your comment to the libusb.org ticket #67. http://www.libusb.org/ticket/67 Take note you still go through all the device but do not try to get all the descriptor information for those device not of interets. The simple filtering can already help many people who are complaining about the performance. So I think it might be able to be achieved before hotplug. -- Xiaofan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
