Create ne w"custom_io" packet sending model #7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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>
Basically, this alows us to hide the usbhid code behind the custom_io abstraction, so that a dive computer could either be given a supplied custom_io structure, of if none is given, would create one for a USBHID device. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This means that they still default to their respective USB devices, but you can now set custom IO structure to pass in your own data. Not only will we hopefully have some kind of BLE support, you could also use this to simply emulate packets from a log-file by having a packet replay (or by actually emulating a device). Of course, you can already do this by actually emulating the device in a virtual environment, but it might be useful for some kind of libdivecomputer testing environment. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
good |
|
I approve. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This creates a new "custom_io" model that can be used to send and receive "packets" over some transport, currently only USBHID.
It also converts the two USBHID backends (Suunto EON Steel and Scubapro G2) to use that custom IO model.
The plan is to be able to then replace the USBHID transport with a BLE GATT-based transport fairly transparently to the libdivecomputer backends (I say "fairly", because the packetization is going to be exposed, and each dive computer backend will inevitably see some transport specifics because they have their own logic of how to encode the stream over the packet interface).