On Wed, Apr 19, 2017 at 12:17:41PM -0700, Linus Torvalds wrote: > Dirk, Anton, (and possibly others who currently use RFCOMM), > > would you mind taking a look at my "ble-prep" branch in > > https://github.com/torvalds/subsurface-for-dirk.git ble-prep > > that I have *not* made into a pull request yet, because I don't > actually have anything to test with.
I'll get you two devices tomorrow, one that does BTLE (Perdix AI) and one that does rfcomm (Petrel). > It's really just three commits: > > custom serial: pass device_data_t to bluetooth operation function > Expand 'bluetooth_mode' from a boolean to an emun > Prepare to split the custom serial operations up by RFCOMM-vs-BLE > > and each of them actually tries to be a total no-op at this time. But > the intent is to make it possible for core/qtserialbluetooth.cpp to > simply have a different set of operations for BLE devices where RFCOMM > doesn't work. I looked at the code and it makes sense to me. I assume the debug fprintf in the last one is there intentionally... :-) > My plan (which may or may not work) would actually be to turn the > Suunto EON Steel into a user of the serial emulation code too, for the > BLE case there - even though the native model for the EON Steel isn't > really "serial" at all, but a packet format with command/reply on top > of USB HID (and now on top of BLE GATT with the new firmware). But I > think it should probably be possible to use the same serial > abstraction to then write the BLE packets instead. At least with the Perdix AI that should in theory be all that it takes. > But that series of three commits doesn't do any of that. It just tries > to do no-op prep on code that I don't actually know at all, which is > why I'd like somebody else to take a look at it. > > In particular, somebody should probably test that it still works with > the RFCOMM model. I'm particularly worried about devices that can do > *both* traditional bluetooth *and* BLE. Because right now it just says > that if the device can do BLE, we'll pick the BLE model. Of course, > right now that BLE model ends up falling back to the same old RFCOMM > code (which would fail on a BLE-only device), so it should still work > with a "RFCOMM *and* BLE" device, but whatever.. > > Comments? I need to check back with Shearwater - I think they have some devices that do both, rfcomm and BTLE > And yes, if somebody who actually knows that code (I'm looking at you, > Anton) actually knows the Qt bluetooth interfaces and would fill in > the open/close/read/write cases for the GLE GATT case, that would be > great. Because right now I have a device that can do BLE, but going > from "USB HID" to "BLE GATT" is a fairly big step. For example, it's a > packetized protocol, and the packet size has changed. > > In contrast, somebody who has a Perdix and already knows it, may have > a much simpler time with the protocol that is already just a serial > stream and isn't really packetized (and the BLE GATT thing is just a > transport for that). See above. I'll get you the hardware tomorrow (I'll fly home tonight). But that shouldn't stop Anton from commenting / working on the code :-) /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface