On Tue, Nov 12, 2013 at 09:51:04AM +0100, Bert Vermeulen wrote: > > > For those that can't though, it's less clear what we should do. In a GUI > > frontend, we want to be able to take advantage of the ability to scan > > for serial ports and then offer the user a list of candidates to choose > > from for a given driver, rather than having to type one in. But what > > call should be made to get that list? > > Clearly this will need a new API call, both publicly and in the internal > driver API.
Yes. > The driver just asks libserialport, supplying any info it has on what > kind of serial port it wants: the driver might know for sure the port > is behind a specific VID/PID, for example. I'd be inclined to do this the other way round; give the driver the list of what's available and then let it go through and match the ones it's interested in. Otherwise, we have to create some sort of intermediate format for drivers to specify what they're interested in, write code to support it, and worry whether it covers all the cases we might need. And we don't gain anything from that effort. > The driver also needs to return to the frontend some measure of > confidence about each port it returns to the frontend. I see a need for > only two indications: the port _might_ be connected to the driver's > supported device (e.g. uses a specific VID/PID that is nevertheless not > unique -- generic FTDI, say). The second indication is if the driver > concludes that this absolutely _is_ a supported device, for example by a > unique VID/PID behind it, or other matching USB descriptors. Yes, exactly. > > It seems like it would be good to have some sort of shared "pre-scan" > > for usable hardware (serial ports, USB devices, and whatever else). > > Each driver could then look through the results to identify the ones > > that it might be able to use. This would be more efficient and would > > allow us to present better UI to the user. > > I'm not so sure this is really needed -- a scan for ports is not an > expensive operation. I'm not convinced yet that it won't become annoying on some operating systems, especially once there are a sufficient number of drivers. The current enumeration operations in libserialport on the "big three" OSes seem reasonably quick, but I'm not certain yet if that will always be the case. In particular enumeration of serial ports on Windows is a mess. There is a library for this (http://www.naughter.com/enumser.html) which has been in development for 15 years and implements 9 different methods, all of which were apparently necessary in some situation on some version. I have implemented just one of these, which seems to be sufficient in all sane cases on non-ancient versions of Windows, but really who knows. On various Unices other than Linux and OS X, enumerating ports looks like it can only be done by grepping through previous kernel messages or trying to open() everything in /dev/ that might be one. This may not be fast either. > libserialport might even cache this list to save even this effort -- > it's static once eumerated, after all. No, absolutely it is not. The available ports can change at any time as hardware is hotplugged and so libserialport should never cache the list. If libsigrok wants to cache the list it will need to wrap the call. We've already discussed the need to support hotplug in libserialport eventually, and I've made changes to the initial API in order to make this easier to introduce in future. Martin ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
