This function no longer exists, it was subsumed by the new
DC_IOCTL_BLE_GET_NAME ioctl instead. The declaration for it had just
not been removed when the definition went away.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge Jef's upstream changes:
- some stream IO abstraction updates: poll() support, but also a new
ioctl() interface to query the BLE name of the stream instead of our
own 'get_name()' function.
This will require corresponding changes on the subsurface side.
- Jef merged the Oceanic BLE support from me, with changes, and some
general atom2 backend cleanups.
- misc small fixups like the 3s Mares BLE timeout we already had.
* git://github.com/libdivecomputer/libdivecomputer:
Install the ioctl header file
Advertise the BLE support in the device descriptors
Fix the BLE device detection for the i770R and Pro Plus X
Implement the BLE handshaking
Implement the BLE packet sending and receiving
Read the entire data packet in a single operation
Remove the trailing zero byte from all commands
Fix a bug in the ACK/NAK handling
Remove an unnecessary function
Add an ioctl to retrieve the remote device name
Re-implement the set_latency function as an ioctl
Add an ioctl function to the I/O interface
Integrate the new poll function
Add a poll function to the I/O interface
Add support for the Oceanic Veo 4.0
Increase the timeout to 3 seconds
The set_latency function is the perfect example of a feature that should
be implemented as an ioctl: it's only implemented by a single driver,
and the functionality is also highly platform specific.
This new ioctl function allows to perform I/O stream specific requests
through a generic interface. This provides an easy way to extend the I/O
interface with some driver specific features, without having to modify
the public api.
The Linux implementation is very straighforward and just a lightweight
wrapper around the select function. But the Windows implementation is
much more complex, because the Windows event notification mechanism
behaves very different:
The WaitCommEvent function does not support a timeout and is always a
blocking call. The only way to implement a timeout is to use
asynchronous I/O (or overlapped I/O as it's called in the Windows API),
to run the operation in the background. This requires some additional
book keeping to keep track of the pending background operation.
The event mechanism is also edge triggered instead of level triggered,
and reading the event with the WaitCommEvent function clears the pending
event. Therefore, the state of the input buffer needs to be checked with
the ClearCommError function before and after the WaitCommEvent call.
The check before is necessary in case the event is already cleared by a
previous WaitCommEvent call, while there is still data present in the
input buffer. In this case, WaitCommEvent should not be called at all,
because it would wait until more data arrives.
The check afterwards is necessary in case WaitCommEvent reports a
pending event, while the data in the input buffer has already been
consumed. In this case, the current event must be ignored and
WaitCommEvent needs to be called again, to wait for the next event.
Some of the transport types have meaningful names.
The BLE transport has a device name that was exposed during device
discovery, for example, and some back-ends (ok, right now only the
Aqualung i300C and i770R) need to know what that device name was in
order to handshake with the device properly.
Other transports, like the USBSTORAGE one, could usefully use this to
get the basename of the path to the storage, although right now that
transport makes do with simply doing a "dc_iostream_read()" on the
transport instead.
For now, this is just the infrastructure, ready to get hooked into.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge the initial Garmin Descent Mk1 support.
This actually works well enough to be useful, even though there are a
few ugly details yet to be sorted out.
The download itself is fairly complete, but all event handling is
currently missing (warnings, gas changes, things like that).
Also, because of how libdivecomputer works, the "downloading" of dives
is entirely separate from the "parsing" of dives in the libdivecomputer
world. And that is actually problematic for the Garmin Descent
downloader, because you actually need to parse the data to even figure
out whether it's actually a dive at all!
The Garmin Descent is also a fitness and general excercise tracker, so
people can (and do) use it for other sports than just diving, and so the
activities we download may end up not being dives at all, but other
events.
But before we parse them, we don't know, and we aren't really supposed
to parse them until after we've passed the data to the application and
it passes it back for parsing. Nasty chicken-and-egg problem there..
So right now non-diving activities will just show up as very short
and/or shallow dives.
This is fixable by just parsing things an extra time, but I really wish
libdivecomputer would just stop thinking that downloading and parsing
are separate events.
* garmin-descent:
Add dc_usb_storage_open to the symbols list
garmin: only record gasmixes for cylinders that aren't enabled
garmin: don't emit fake device info and vendor event
garmin: add support for downloading gas mixes
garmin: add GPS coordinate data and improve parser_get_field() reports
garmin: actually start using the parsed data
garmin: turn all the remaining unrecognized fields into DEBUG messages
garmin: add a lot of new field definitions
garmin: teach the parser to show undefined values for unknown fields too
garmin: fix file length header parsing
garmin: teach the parser about invalid values and more dates
garmin: some fields are defined in all message types
Garmin: start parsing definition records
Garmin Descent Mk1: flesh out the actual downloading part
Add Garmin Descent Mk1 skeleton
Add 'USB storage' transport enumeration
We now have at least two dive computers that enumerate as USB storage
devices: the Uemis Zurich and the Garmin Descent Mk1.
The Uemis is handled purely inside of subsurface, with no
libdivecomputer support. That was likely a mistake, but it was not
practical to do a libdivecomputer backend for it at the time.
The Garmin Descent Mk1 support would be much nicer to have natively in
libdivecomputer, and looks much more relevant and practical than the
Uemis situation was.
So start off with defining a new transport type.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add a function to query the underlying transport type. This allows the
dive computer backends to implement transport specific behaviour where
necessary.
For the built-in I/O implementations, the transport type is obviously
always hardcoded, but for a custom I/O implementation the application
needs to provide the correct type. Hence the transport type can't be
hardcoded in the vtable and needs to be passed as a parameter.
The purpose of the new I/O interface is to provide a common interface
for all existing I/O implementations (serial, IrDA, bluetooth and USB
HID). With a common interface the dive computer backends can more easily
use different I/O implementations at runtime, without needing
significant code changes. For example bluetooth enabled devices can
easily switch between native bluetooth communication and serial port
emulation mode.
The new interface is modelled after the existing serial communication
api. Implementations where some of those functions are meaningless (e.g.
IrDA, bluetooth and USB), can just leave those functions unimplemented
(causing the call to fail with DC_STATUS_UNSUPPORTED), or implement it
as a no-op (always return DC_STATUS_SUCCESS).
