Merge with upstream:
- support for the OSTC 2 TR
- add support for dive computer filtering for device discovery
- various cleanups particularly to timestamp handling
- remove half-duplex emulation from the I/O api
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Remove the half-duplex emulation from the I/O api
Handle the half-duplex emulation in the vyper2 backend
Use the new timer for the timestamps in the logging
Use the new timer for the timeout calculations
Add a high resolution timer module
Add functions for converting bluetooth addresses
Add support for the OSTC 2 TR
Add a workaround for invalid logbook begin pointers
Let the ringbuffer function handle a full ringbuffer
Suppress the warning if no O2 sensors are present
Integrate the connect step into the open function
Implement some filter functions
Add suport for applying a filter function
Re-write the device discovery using the iterator api
Cleanup the iterator internals
The serial ops used a legacy calling convention that passed in just the
pointer to the userdata pointer (ie the first argument to the functions
was "void **userdata").
That's actually very inconvenient, because the custom IO data can not
only contain other interesting information that was filled in by the
custom IO provider, it also made it harder to chain these things
together, as exemplified by the core to emulate serial over the packet
interface in the subsurface bluetooth code.
This also adds the 'dc_context_t' field that is passed to the packet
routine open. That can allow the open routine to override the
'custom_io' details of the context at open time (to allow nested
custom_io operation).
Note that callers of the open function need to be aware that the
'custom_io' can be changed by the act of opening a custom_io, and the
value shouldn't be cached in some local variable.
Finally, this adds a new user-supplied opaque pointer
dc_user_device_t *user_device;
to the custom_io descriptor.
The 'user_device' data is filled in when registering the custom_io with
data that the custom IO open() routines can use. This is different from
the existing 'userdata' in that the 'user_device' is filled in before
dc_open_device() is called (and "open" can then use it to limit what
kinds of devices it looks for, for example).
In contrast, the existing 'userdata' field is filled in by the
"xyz_open()" routines, and contains the data necessary for the IO
itself.
The SSRF_CUSTOM_IO define is updated to v2 to indicate the new
interfaces.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The custom IO handlers will be extended to not just do serial line
emulation (generally over Bluetooth rfcomm), but do BLE too.
BLE does not look like a serial protocol at all, it's packet-based, and
we may have to add specific routines to indicate which GATT endpoints to
use etc. But like the traditional custom serial code, we want to do the
actual IO not from within libdivecomputer, but from the user of the
library (because the BLE support will require things like the Qt
Connectivity layer - and we do not want libdivecomputer to have to link
against something like Qt).
So this renames 'custom_serial' to 'custom_io', and instead names the
individual member function pointers 'serial_*' to make it clear that
those members are for serial communication.
It also adds new placeholders for packet_open/close/read/write. Note
that while these may look similar to the serial counter-parts, they are
not the same or even necessarily mutually exclusive. It is possible the
the caller fills in one or the other (or both), and they would be used
independently.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This re-implements the custom serial concept in a new way. This way
doesn't touch any of the backend code, it just introduces a optional
redirection layer in the existing serial backends.
This implementation supports more serial operations to, so we can
support more backends this way.
Hooking into the existing serial backends might look ugly but its
probably the best way to make sure this patch conflicts as little as
possible with upstream.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In commit 886884ab606def1183d99eca7dec8affefee635e, the custom log
function in the example applications has already been modified to use
high resolution timestamps. But I forgot about the built-in default log
function. So this is basically the same change, but now applied to the
built-in log function.
With the switch to 4K data packets in the Icon HD backend, the internal
log buffer is no longer large enough for hexdumps of these data packets.
A hexdump needs twice the size of the binary data, plus some extra bytes
for the header and the terminating null byte.
Apparantly, the windows wingdi.h header file already defines the
ERROR macro. By defining the NOGDI macro before including the
windows.h header file, we can prevent the wingdi.h file from being
included and thus avoid the warning. We don't need that header for
anything anyway.
Because the libusb header file includes the windows.h file
explicitly, it needs the same fix.
If the maximum availalbe buffer size is zero, no data can be written
(not even the NULL terminator), and a negative values should be returned
to indicate truncation.
The main logging function isn't really suitable for generating inline
hexdumps directly from the binary data. There is simply no format string
available for converting array data types with just a single printf
call.
A possible solution would be to require the caller to perform the string
conversion before calling the standard logging function. But that's not
acceptable, because it doesn't play well with the ability to disable the
logging at compile time, requires extra memory and clutters the calling
code unneccessary.
The new function is a compromise which sacrifices flexibility for
simplicity, by using a hardcoded output format with a custom prefix.
It's not a perfect solution, but it works well enough for the intended
purpose.
The non-standard vsnprintf implementation provided by MSVC doesn't
matches the C99 function. The wrapper function provides a consistent
interface on top of the native functions.
With the new option, the library can be compiled with the entire
logging infrastructure disabled. The public api remains unchanged, but
the internal logging functions will have no effect anymore.
In practice the overhead of the logging functions should be quite
small, and disabling the logging at runtime might be more convenient.
Especially because troubleshooting will become much harder without any
logging.
The new convenience function provides a centralized and threadsafe
function for logging system errors. The previous functions are
deprecated and will be removed after the transition to the new context
based logging.
An application can now register an application defined callback
function, which will perform the actual logging. This provides
additional flexibility compared to logging to stderr with a hardcoded
format. Applications can now easily display the messages in their user
interface, customize the format, etc.
Although the internal logging function is a printf like function, the
arguments are converted into a plain string before being passed to the
callback function. This greatly improves interoperability with
programming languages which don't support C style variadic functions
(e.g. Python, C#, etc).
With the introduction of a context object, library initialization and
shutdown can be performed without requiring any global state. A single
process can use multiple independent contexts without any problems. The
lack of a global state also improves the thread-safety of the library.
At the moment, the new context object is primary used to implement an
improved logging system.
