Hi Thomas, On Sun, Dec 08, 2013 at 05:17:54PM +0100, Thomas Haber wrote: > > >Be aware that since the libsigrok and libsigrokdecode APIs are the > >normal method of accessing sigrok functionality, you're going to be > >on your own going through the CLI. It is intended as an end-user tool > >and there is no guarantee that options, output formats and so forth > >will not change without warning in future versions. > > I undestand ! Problem is that i'm not getting sufficient > informations about the devices from it. I would like to make the > dialog more usable like a combo with the available devices or > available rates. With scan i get the device names but don't get the > associated drivers/device.
The first thing in each line returned by --scan is the driver name, which is what is required by the --driver option. You can get a list of supported drivers, input/output formats and protocol decoders with --version. The --show option will list supported settings for a given device. You are welcome to submit bug reports or patches if you feel that sigrok-cli could be improved by outputting additional information, but do bear in mind that these would be considered in terms of whether they improve sigrok-cli for the end user. It's not the aim of the program to provide a machine-readable CLI mapping of all libsigrok functionality. I would note also that although it's a commonly used guideline, the fact of going through an existing CLI doesn't automatically imply compliance with the terms of the GPL. The real question is whether what you are producing is a "derived work" of the GPL code in the specŃ–fic legal sense of that term, which is harder to answer definitively. To provide some comparison: Eclipse is often integrated with GCC, by calling GCC on the command line and working with its output. In that instance any other compiler could be substituted, so it's hard to argue that the result is a "derived work" of GCC, and this is generally considered OK. In this case however, you are adding code specifically to interface with sigrok - no other existing software could be substituted. As the level of integration increases it becomes progressively harder to argue that the result is not a derived work. There's a limit somewhere, and I can't autoritatively tell you where it is. Sorry for the lecture - I just don't want to see anyone running off selling fancy software that looks for all intents and purposes like it's linked with libsigrok but is actually calling sigrok-cli behind the scenes for everything, and then claim that's permitted because some dev said so on the mailing list... Also: I don't speak for the rest of the project here, only for myself. Martin ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
