Since input modules determine a samplerate by reading from their
file format (or having it overridden with an option), they need
to pass this up to the frontend.
I had a binary file that I needed to decode using UART decoder. UART
decoder needs to know the sample rate for the data, but currently it's
not possible to pass parameters to input formats and so the "binary"
file format always sets the samplerate to 0.
This patch adds the possibility to append a colon-separated list of
key=value options to the -I argument, in the same way -d supports it.
Also, it makes the "binary" format support the "samplerate" option.
I included the GHashTable containing input format options directly in
the sr_input struct. I'm not sure if that's the right way to do it. I
saw that -d uses a much more elaborate system with device capabilities
and typed options, but that seemed like an overkill for input formats.
All frontends will have to include <libsigrok/libsigrok.h> from now on.
This header includes proto.h and version.h, both installed from the
distribution into $INCLUDE/libsigrok/ as well.
The only dynamically changed header is now version.h, which has both
libsigrok and libtool compile-time versions in it.
All ChronoVu LA8 files (*.kdt extension usually) are exactly 8388613
bytes in size (8MB + 5 bytes). Check this, when trying to autodetect the
file format, to reduce the likelihood of 'chronovu-la8' being
autodetected on all binary files (instead of 'binary').
Avoid plain malloc()/free() in sr/srd, especially in the API calls.
Also avoid g_malloc*() in favor of g_try_malloc*().
Use g_strdup() instead of strdup() so that we can use g_free()
consistently everywhere.
Exceptions: Stuff that is allocated via other libs (not using glib),
should also be properly free'd using the respective free-ing function
(instead of g_free()). Examples: Stuff allocated by libusb, libftdi, etc.
Also, use sr_err() instead of sr_warn() for actual errors. sr_warn() is
meant for non-fatal/uncritical warnings.
This will come back in some form or another later, but for now
don't clutter the API with non-working stuff. Removing stuff from APIs
is not possible without breaking the API, adding stuff later is simpler.
Bert Vermeulen
Uwe Hermann
Tomaž Šolc