Re: [GSoC] Week 3 (Native Bluetooth support)
Dirk, Sorry for the slow response. Been busy with real life. On 2015-06-17 16:45, Dirk Hohndel wrote: I don't know which other apps use libdivecomputer, but the ones that I know about... Subsurface: happy to implement a Bluetooth backend, happy to use the existing libdivecomputer communication layer otherwise MacDive: doesn't use libdivecomputer at all for communication and only uses some of your parsers I think you are mistaken here. As far as I know, Macdive does use libdivecomputer for the communication (except for the cobalt I believe). You are right that Macdive has a few custom parsers, but that's mainly for historic reasons. Back in the early days, libdivecomputer didn't support some features that MacDive needed. Nowadays we support most of them, but you know: if it ain't broken don't fix it :-) DivingLog: wouldn't know which end of a C library is up and therefore has you do all his work for him. Couldn't implement a low-level I/O function to save his business model (OK, that was harsh, but I'll be interested in someone proving me wrong) Anyone is free to use his/her preferred programming language for his/her own project, right? I can't write an application in assembler (and many other programming languages) either :-) I'm sure it will be possible to write a low-level I/O backend in .NET too. Who else? There are many more. I maintain a (possible incomplete) list on the libdivecomputer website: http://libdivecomputer.org/links.html#applications My point is... does the fact that you implement all of the dive computer code for DivingLog impact your view of what other applications might want from libdivecomputer? No it doesn't. I think you greatly overestimate my involvement with Diving Log. Yes, I did spend quite some time to figure out how to use libdivecomputer from .NET code (and by doing that I learned how to make sure that the public api is usable from non C/C++ code). But that's already several years ago. Nowadays it's limited to building the libdivecomputer dll and notifying Sven about changes when necessary. I have (and need) the windows build setup anyway, so why not? It's just a few minutes of work once in a while. And applications benefit from being able to add things that aren't in libdivecomputer and that likely won't be in libdivecomputer for a lng time. When do you think your Android Bluetooth support will be ready to ship? What about your Mac Bluetooth support? If we can have a callback into the app then we'll have both working in Subsurface by the end of this summer. I think you already know my answer: I have no idea, but definitely not by the end of this summer. (Note that a callback based interface won't be available by that time either.) But nobody says you have to wait until *I* have time to implement some code for Android, Mac or whatever OS. Patches with support for those OS'es are always welcome... I'm aware there are good technical arguments in favor of a custom I/O layer too. For example a Qt based application like subsurface can easily take advantage of the bluetooth support in the Qt framework, while other applications may not appreciate such a (huge) dependency. But that's another story. 2. If applications are responsible for the low-level communication, then the list of supported dive computers will depend on which protocols have been implemented by the application. Thus two applications using the same libdivecomputer library may not support the same set of dive computers. That's not only confusing, but may also give closed source applications a competitive advantage: A closed source application could implement a low-level communication backend and decide not to share it with everyone else. (This might be considered an ideological issue, and not a technical one. But since this happens to be one of the reason why libdivecomputer is an open source library, this matters to me!) You are missing the point. Really. We are not saying stop doing it in libdivecomputer. We are saying offer the app a chance to register a callback. If it's there, use it. If it isn't, do what you are doing today. That was a bit of a misunderstanding then. I initially understood you wanted to keep all bluetooth code out of libdivecomputer, and have the custom backend as the only option. 3. Right now, the api for the low-level communication is a private api. This has several advantages. First of all, that allows me to change the api when necessary, without having to worry about backwards compatibility. Once I provide some callback interface, that will become part of the public api. But that's not all. Second, and even more important, is that a custom communication backend won't be able to take advantage of other internal api's, like the logging infrastructure. That's a really important feature for me, because it greatly simplifies troubleshooting and debugging. 4. We already have a working proof of
Re: [GSoC] Week 3 (Native Bluetooth support)
On Wed, Jul 15, 2015 at 08:57:22AM +0200, Jef Driesen wrote: Sorry for the slow response. Been busy with real life. I know that feeling well. On 2015-06-17 16:45, Dirk Hohndel wrote: I don't know which other apps use libdivecomputer, but the ones that I know about... Subsurface: happy to implement a Bluetooth backend, happy to use the existing libdivecomputer communication layer otherwise MacDive: doesn't use libdivecomputer at all for communication and only uses some of your parsers I think you are mistaken here. As far as I know, Macdive does use libdivecomputer for the communication (except for the cobalt I believe). You are right that Macdive has a few custom parsers, but that's mainly for historic reasons. Back in the early days, libdivecomputer didn't support some features that MacDive needed. Nowadays we support most of them, but you know: if it ain't broken don't fix it :-) I will let Nick comment on that if he wants to. I spent a lot of time discussing implementation ideas with Nick in Fiji earlier this year and am reasonably certain that my comments above are indeed correct. And applications benefit from being able to add things that aren't in libdivecomputer and that likely won't be in libdivecomputer for a lng time. When do you think your Android Bluetooth support will be ready to ship? What about your Mac Bluetooth support? If we can have a callback into the app then we'll have both working in Subsurface by the end of this summer. I think you already know my answer: I have no idea, but definitely not by the end of this summer. (Note that a callback based interface won't be available by that time either.) But nobody says you have to wait until *I* have time to implement some code for Android, Mac or whatever OS. Patches with support for those OS'es are always welcome... Your definition of patches are welcome and my definition of that phrase are very different. I respect your right to run your open source project the way you see fit. I simply disagree with it. We talked about this at length last fall in Duesseldorf and I won't try to rehash that conversation here. But the perfectly functional, well tested and fairly complete DC_FIELD_STRING implementation in our branch of Subsurface can serve as a good example. So for a GSoC student to be dependent on any changes making it into libdivecomputer is a complete non-starter. Which is why I asked Claudiu to continue down the path he started on. And he's making great progress. 2. If applications are responsible for the low-level communication, then the list of supported dive computers will depend on which protocols have been implemented by the application. Thus two applications using the same libdivecomputer library may not support the same set of dive computers. That's not only confusing, but may also give closed source applications a competitive advantage: A closed source application could implement a low-level communication backend and decide not to share it with everyone else. (This might be considered an ideological issue, and not a technical one. But since this happens to be one of the reason why libdivecomputer is an open source library, this matters to me!) You are missing the point. Really. We are not saying stop doing it in libdivecomputer. We are saying offer the app a chance to register a callback. If it's there, use it. If it isn't, do what you are doing today. That was a bit of a misunderstanding then. I initially understood you wanted to keep all bluetooth code out of libdivecomputer, and have the custom backend as the only option. Not at all. I want the ability to have that code in Subsurface BECAUSE I don't want to add a Qt dependency to libdivecomputer. And because I don't want to make my custom branch of libdivecomputer even more divergent from your master branch than it already is. To me, the less code I need to add to or change in libdivecomputer, the better. 4. We already have a working proof of concept for native bluetooth communication, which supports Linux and Windows. So I don't see any reasons why we would need a custom implementation there. Because you don't understand how other apps besides DivingLog want to use your library. If it's not available on Mac it doesn't help about a quarter of my users. And I expect that by the end of summer we'll have an Android app as well and I'll bet good money that that will be quite popular very quickly. And the main reason all the dive computer vendors are coming out with BT devices is because it's so hard to do USB downloads on Android and IOS. So you want this functionality for *YOUR* users. Am I right that you probably don't really care much about other applications? Although I can understand such point of view, that's exactly the point I wanted to make! Of course I want it for the Subsurface users. I am pushing for changes in libdivecomputer that make it easier for the consumers of
Re: [GSoC] Week 3 (Native Bluetooth support)
On 2015-06-15 20:26, Thiago Macieira wrote: On Monday 15 June 2015 06:13:54 Dirk Hohndel wrote: On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote: I did already think about this :-) See [1] for some more background info. In a nutshell, the serial layer will be changed from a concrete implementation into an abstract interface. This will allow us to have multiple implementations: native (using kernel drivers), bluetooth (using rfcomm sockets), usb-serial (cdc-acm, ftdi, pl2303, cp210x), etc What about allowing the calling application to handle the creation of a serial communication stream and simply providing a callback to do so? Or am I missing another implementation issue here (it's been too long that I dug deeply into that part of libdivecomputer code) Right. Jef, can we have an API that allows the application to pass a set of function pointer callbacks for all the operations that libdc needs to do? Assume that the device. You probably need open, close, read, write, but what else? This way, the application can redirect the I/O through whichever other means it has at its disposal. I'm not convinced application provided callback functions are the right solution, for the following reasons: 1. If the application has to provide the low-level I/O functions, that means *every* single application will have to re-implement this functionality on its own. That will require a significant amount of extra work, especially when the low-level I/O is not trivial. And the fact that we are having this discussion is definitely a sign that bluetooth communication is not trivial. That's why I believe libdivecomputer should provide the low-level communication. All applications will benefit from having a common implementation. 2. If applications are responsible for the low-level communication, then the list of supported dive computers will depend on which protocols have been implemented by the application. Thus two applications using the same libdivecomputer library may not support the same set of dive computers. That's not only confusing, but may also give closed source applications a competitive advantage: A closed source application could implement a low-level communication backend and decide not to share it with everyone else. (This might be considered an ideological issue, and not a technical one. But since this happens to be one of the reason why libdivecomputer is an open source library, this matters to me!) 3. Right now, the api for the low-level communication is a private api. This has several advantages. First of all, that allows me to change the api when necessary, without having to worry about backwards compatibility. Once I provide some callback interface, that will become part of the public api. But that's not all. Second, and even more important, is that a custom communication backend won't be able to take advantage of other internal api's, like the logging infrastructure. That's a really important feature for me, because it greatly simplifies troubleshooting and debugging. 4. We already have a working proof of concept for native bluetooth communication, which supports Linux and Windows. So I don't see any reasons why we would need a custom implementation there. If Qt supports discovery, pairing, etc there is nothing preventing you from using those features, and let libdivecomputer take care of the actual communication. I quickly checked the Qt implementation for Linux, and they are using the same socket based api as my proof of concept. So under the hood it's the same. I'm also not ruling out an (optional) dependency on Qt for the other platforms like Mac OS X, iOS, Android. Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On Wed, Jun 17, 2015 at 04:20:42PM +0200, Jef Driesen wrote: On 2015-06-15 20:26, Thiago Macieira wrote: On Monday 15 June 2015 06:13:54 Dirk Hohndel wrote: On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote: I did already think about this :-) See [1] for some more background info. In a nutshell, the serial layer will be changed from a concrete implementation into an abstract interface. This will allow us to have multiple implementations: native (using kernel drivers), bluetooth (using rfcomm sockets), usb-serial (cdc-acm, ftdi, pl2303, cp210x), etc What about allowing the calling application to handle the creation of a serial communication stream and simply providing a callback to do so? Or am I missing another implementation issue here (it's been too long that I dug deeply into that part of libdivecomputer code) Right. Jef, can we have an API that allows the application to pass a set of function pointer callbacks for all the operations that libdc needs to do? Assume that the device. You probably need open, close, read, write, but what else? This way, the application can redirect the I/O through whichever other means it has at its disposal. I'm not convinced application provided callback functions are the right solution, for the following reasons: 1. If the application has to provide the low-level I/O functions, that means No one suggested that the application HAS to provide that functionality. What we are suggesting is to make this an OPTION. If the application wants to do this... I don't know which other apps use libdivecomputer, but the ones that I know about... Subsurface: happy to implement a Bluetooth backend, happy to use the existing libdivecomputer communication layer otherwise MacDive: doesn't use libdivecomputer at all for communication and only uses some of your parsers DivingLog: wouldn't know which end of a C library is up and therefore has you do all his work for him. Couldn't implement a low-level I/O function to save his business model (OK, that was harsh, but I'll be interested in someone proving me wrong) Who else? My point is... does the fact that you implement all of the dive computer code for DivingLog impact your view of what other applications might want from libdivecomputer? *every* single application will have to re-implement this functionality on its own. That will require a significant amount of extra work, especially when the low-level I/O is not trivial. And the fact that we are having this discussion is definitely a sign that bluetooth communication is not trivial. That's why I believe libdivecomputer should provide the low-level communication. All applications will benefit from having a common implementation. And applications benefit from being able to add things that aren't in libdivecomputer and that likely won't be in libdivecomputer for a lng time. When do you think your Android Bluetooth support will be ready to ship? What about your Mac Bluetooth support? If we can have a callback into the app then we'll have both working in Subsurface by the end of this summer. 2. If applications are responsible for the low-level communication, then the list of supported dive computers will depend on which protocols have been implemented by the application. Thus two applications using the same libdivecomputer library may not support the same set of dive computers. That's not only confusing, but may also give closed source applications a competitive advantage: A closed source application could implement a low-level communication backend and decide not to share it with everyone else. (This might be considered an ideological issue, and not a technical one. But since this happens to be one of the reason why libdivecomputer is an open source library, this matters to me!) You are missing the point. Really. We are not saying stop doing it in libdivecomputer. We are saying offer the app a chance to register a callback. If it's there, use it. If it isn't, do what you are doing today. This way our download dialog can have a button use Bluetooth. If that's clicked we register the callbacks and do the communication ourselves. If it isn't, we use libdivecomputer just like we do today. 3. Right now, the api for the low-level communication is a private api. This has several advantages. First of all, that allows me to change the api when necessary, without having to worry about backwards compatibility. Once I provide some callback interface, that will become part of the public api. But that's not all. Second, and even more important, is that a custom communication backend won't be able to take advantage of other internal api's, like the logging infrastructure. That's a really important feature for me, because it greatly simplifies troubleshooting and debugging. 4. We already have a working proof of concept for native bluetooth communication, which supports Linux and Windows. So I don't see any
Re: [GSoC] Week 3 (Native Bluetooth support)
Hi, On 17.06.2015, at 16:45, Dirk Hohndel d...@hohndel.org wrote: No one suggested that the application HAS to provide that functionality. What we are suggesting is to make this an OPTION. If the application wants to do this... I did not follow this discussion in all details. But maybe I can expand a little bit what Dirk is saying here. (And yes, due to my ignorance, what I am suggesting could be total bs.) I think what Dirk has in mind, you rename some functions in your API and give them additional callback arguments (like to a function that behaves like open and one that behaves like close). Then the application can provide those functions that might be doing something else (like first pairing etc). In libdivecomputer, you replace the direct calls to open and close by the callbacks and finally you add wrapper functions with the old API names that behave like the old API by calling the renamed functions with callbacks to the traditional versions of open and close. (And “you” in that case does not mean it has to be Jef who is actually coding this). In this way, you stay backwards compatible but give applications the chance to do a little setting up for the actual communication. I hope this makes sense. (And I admit I do not see how this relates to your point about open sourceless of ldc). Best Robert -- .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO Robert C. Helling Elite Master Course Theoretical and Mathematical Physics Scientific Coordinator Ludwig Maximilians Universitaet Muenchen, Dept. Physik Phone: +49 89 2180-4523 Theresienstr. 39, rm. B339 http://www.atdotde.de Enhance your privacy, use cryptography! My PGP keys have fingerprints A9D1 A01D 13A5 31FA 6515 BB44 0820 367C 36BC 0C1Dand DCED 37B6 251C 7861 270D 5613 95C7 9D32 9A8D 9B8F signature.asc Description: Message signed with OpenPGP using GPGMail ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On 15 June, 2015 - Claudiu Olteanu wrote: Ok. In the beginning I will try to implement the downloading entirely in Subsurface and re-implement the dive computer protocol for HW OSTC family. I think this is a bad path. I would rather suggest something like implementing a serial backend in libdivecomputer which takes a Qt5-Bluetooth-thingie to work with. The same thoughts have bin about having libftdi-serial-backends and cdc-serial-backends to support platforms where kernel-drivers for those aren't a option (Android). This is rather a puck for Jef to think about how a dc_device_open version which passes on parameters for different backends. I could see a dc_device_open which takes something else than just a const char *name, rather a dc_serial_type_t, and a void *arg. I could see something like a dc_serial_type_t SERIAL which takes a regular char* and is implemented with the regular serial.c backend, and a QT5_BLUETOOTH, which gets a Qt-bluetooth-object-thingie, and a FTDI which gets the correct args for a ftdi_usb_open to succeed. //Anton - Spending his 2c while in a teleconference. -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On 2015-06-15 13:46, Anton Lundin wrote: On 15 June, 2015 - Claudiu Olteanu wrote: Ok. In the beginning I will try to implement the downloading entirely in Subsurface and re-implement the dive computer protocol for HW OSTC family. I think this is a bad path. I would rather suggest something like implementing a serial backend in libdivecomputer which takes a Qt5-Bluetooth-thingie to work with. The same thoughts have bin about having libftdi-serial-backends and cdc-serial-backends to support platforms where kernel-drivers for those aren't a option (Android). This is rather a puck for Jef to think about how a dc_device_open version which passes on parameters for different backends. I could see a dc_device_open which takes something else than just a const char *name, rather a dc_serial_type_t, and a void *arg. I could see something like a dc_serial_type_t SERIAL which takes a regular char* and is implemented with the regular serial.c backend, and a QT5_BLUETOOTH, which gets a Qt-bluetooth-object-thingie, and a FTDI which gets the correct args for a ftdi_usb_open to succeed. I did already think about this :-) See [1] for some more background info. In a nutshell, the serial layer will be changed from a concrete implementation into an abstract interface. This will allow us to have multiple implementations: native (using kernel drivers), bluetooth (using rfcomm sockets), usb-serial (cdc-acm, ftdi, pl2303, cp210x), etc Instead of passing a device name to the dc_device_open() function, the application will first need to create an instance of one of those serial backends (with the appropriate parameters), and pass that one: dc_serial_t *serial = NULL; dc_device_t *device = NULL; /* Open the low-level communication transport. */ dc_serial_native_open(serial, devname); dc_serial_rfcomm_open(serial, address, channel); dc_serial_usbserial_open(serial, vid, pid); /* Connect to the dive computer. */ dc_device_open(device, ..., serial); /* Do something useful here. */ /* Close the connection. */ dc_device_close(device); dc_serial_close(serial); Although this will clearly require some extra code on the application side, there are other advantages too. For example it will be possible to expose functions for device enumeration. The code is already there, but applications can't use it, because the serial layer is a completely private api. [1] http://libdivecomputer.org/pipermail/devel/2014-June/000305.html Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote: I did already think about this :-) See [1] for some more background info. In a nutshell, the serial layer will be changed from a concrete implementation into an abstract interface. This will allow us to have multiple implementations: native (using kernel drivers), bluetooth (using rfcomm sockets), usb-serial (cdc-acm, ftdi, pl2303, cp210x), etc What about allowing the calling application to handle the creation of a serial communication stream and simply providing a callback to do so? Or am I missing another implementation issue here (it's been too long that I dug deeply into that part of libdivecomputer code) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On Mon, Jun 15, 2015 at 12:19:32PM +0300, Claudiu Olteanu wrote: Ok. In the beginning I will try to implement the downloading entirely in Subsurface and re-implement the dive computer protocol for HW OSTC family. To be honest I believe that a better idea would be to continue the work you started and to use directly the BlueZ stack instead of Qt Bluetooth API. In this way I won't re-implement the dive computer communication protocol, I will add Bluetooth support to libdivecomputer and I will use it in the Subsurface project. The only thing I can't imagine is how libdivecomputer will expose functionalities like pairing/scanning/hci control. Part of what you are learning in GSoC is that sometimes we start projects with incorrect assumptions and as we understand problems better we come up with different solutions. It is entirely reasonable for you to say the initial design idea was wrong, here's a better approach how to do this. I am not at all opposed to turn this into a project that includes modifications to libdivecomputer instead. Given the lack of Bt support on Windows when just using bluez I wonder if there is value in Anton's idea to modify libdivecomputer to use a callback to open a serial connection and then have Subsurface (or other consumers of libdivecomputer) provide that serial stream back to libdivecomputer. This way we could still use QtBluetooth on the Subsurface side but benefit from the libdivecomputer download algorithms. Does this seem like a reasonable direction? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On Mon, Jun 15, 2015 at 09:20:44PM +0300, Claudiu Olteanu wrote: Given the lack of Bt support on Windows when just using bluez I wonder if there is value in Anton's idea to modify libdivecomputer to use a callback to open a serial connection and then have Subsurface (or other consumers of libdivecomputer) provide that serial stream back to libdivecomputer. This way we could still use QtBluetooth on the Subsurface side but benefit from the libdivecomputer download algorithms. Does this seem like a reasonable direction? /D Yes, it is a reasonable direction but I have to remind you that *QtBluetooth* doesn't have support for Windows. They probably started to work on it [1] but there is no information about the release date. The reason we explored QtBluetooth was that I was told that in Qt5.5 it was going to support all our platforms. It appears that this was wrong an it supports all except for Windows :-( Therefore for Windows we should use the *MS Bluetooth* stack. The same technology is used/will be used in *libdivecomputer* project. The only benefit with *QtBluetooth* API is that it has support for OSx, iOS, Android and Linux. You are right. I am not against *QtBluetooth* API, because I am already accommodated with the API but I believe that it would be more beneficial for both projects to have the Bluetooth implementation in the *libdivecomputer* project, since it is already started. OK. How are you going to implement the OS X Bluetooth stack in libdiveceomputer? How about Android? And (here's hoping) IOS? I am a little confused about which direction to go. I read the link suggested by Jef and there are some drawbacks mentioned. Also, the discussions were from 2014 and I don't know if any idea from there was taken into consideration and it will be used in a new release. I remember that Jef said that he intends to do some major changes on the API in the next release. Also I believe that it would be helpful if the new API will allow applications to open the low-level communication transport (already implemented in the *libdivecomputer*, like Jef suggested) or to open a custom one implemented in the application which respects the same layout (like Anton suggested). It will require some extra code in the application side but it will cover a lot of usages. In this way we can create our custom implementation with the *QtBluetooth* API for its supported platforms, while for Windows we can finish the implementation from the *libdivecomputer* project. The applications will be responsible to implement features like pairing/scanning/hci control if they want to use Bluetooth protocol for communication and extract the address of the remote device. The job of the *libdivecomputer* will be to assure the communication and the data parsing. It will not be its responsibility to enumerate serial, usb or bluetooth devices or to expose an API to control the devices. Part of the appeal to implement BT in the application and not in libdivecomputer is the whole question of a seamless experience to the user when it comes to pairing with a device. The application creates the communication and allows libdivecomputer to talk to the device through the socket it opened... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On Monday 15 June 2015 06:13:54 Dirk Hohndel wrote: On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote: I did already think about this :-) See [1] for some more background info. In a nutshell, the serial layer will be changed from a concrete implementation into an abstract interface. This will allow us to have multiple implementations: native (using kernel drivers), bluetooth (using rfcomm sockets), usb-serial (cdc-acm, ftdi, pl2303, cp210x), etc What about allowing the calling application to handle the creation of a serial communication stream and simply providing a callback to do so? Or am I missing another implementation issue here (it's been too long that I dug deeply into that part of libdivecomputer code) Right. Jef, can we have an API that allows the application to pass a set of function pointer callbacks for all the operations that libdc needs to do? Assume that the device. You probably need open, close, read, write, but what else? This way, the application can redirect the I/O through whichever other means it has at its disposal. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
Given the lack of Bt support on Windows when just using bluez I wonder if there is value in Anton's idea to modify libdivecomputer to use a callback to open a serial connection and then have Subsurface (or other consumers of libdivecomputer) provide that serial stream back to libdivecomputer. This way we could still use QtBluetooth on the Subsurface side but benefit from the libdivecomputer download algorithms. Does this seem like a reasonable direction? /D Yes, it is a reasonable direction but I have to remind you that *QtBluetooth* doesn't have support for Windows. They probably started to work on it [1] but there is no information about the release date. Therefore for Windows we should use the *MS Bluetooth* stack. The same technology is used/will be used in *libdivecomputer* project. The only benefit with *QtBluetooth* API is that it has support for OSx, iOS, Android and Linux. I am not against *QtBluetooth* API, because I am already accommodated with the API but I believe that it would be more beneficial for both projects to have the Bluetooth implementation in the *libdivecomputer* project, since it is already started. I am a little confused about which direction to go. I read the link suggested by Jef and there are some drawbacks mentioned. Also, the discussions were from 2014 and I don't know if any idea from there was taken into consideration and it will be used in a new release. I remember that Jef said that he intends to do some major changes on the API in the next release. Also I believe that it would be helpful if the new API will allow applications to open the low-level communication transport (already implemented in the *libdivecomputer*, like Jef suggested) or to open a custom one implemented in the application which respects the same layout (like Anton suggested). It will require some extra code in the application side but it will cover a lot of usages. In this way we can create our custom implementation with the *QtBluetooth* API for its supported platforms, while for Windows we can finish the implementation from the *libdivecomputer* project. The applications will be responsible to implement features like pairing/scanning/hci control if they want to use Bluetooth protocol for communication and extract the address of the remote device. The job of the *libdivecomputer* will be to assure the communication and the data parsing. It will not be its responsibility to enumerate serial, usb or bluetooth devices or to expose an API to control the devices. [1] - https://bugreports.qt.io/browse/QTBUG-40698 Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
The reason we explored QtBluetooth was that I was told that in Qt5.5 it was going to support all our platforms. It appears that this was wrong an it supports all except for Windows :-( Well, no.. Sorry to disappoint you. For Qt 5.5 it is planned to offer support for iOS and OS X and a stable Bluetooth Low Energy API. I mentioned this on the proposal and the fact that for Windows we will need to use the MS BT stack. OK. How are you going to implement the OS X Bluetooth stack in libdiveceomputer? How about Android? And (here's hoping) IOS? If we want to have support for this platforms, probably the best choice will be to use the Qt Bluetooth API and let the framework to deal with the differences between the platforms. Because of this I believe that it is a good idea for libdivecomputer to let the application to open its custom communication implementation or to be able to pass callbacks for basic read/write operations. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On Mon, Jun 15, 2015 at 10:03:32PM +0300, Claudiu Olteanu wrote: The reason we explored QtBluetooth was that I was told that in Qt5.5 it was going to support all our platforms. It appears that this was wrong an it supports all except for Windows :-( Well, no.. Sorry to disappoint you. For Qt 5.5 it is planned to offer support for iOS and OS X and a stable Bluetooth Low Energy API. I mentioned this on the proposal and the fact that for Windows we will need to use the MS BT stack. Which just goes to show how much wishful thinking messes with my ability to read :-( OK. How are you going to implement the OS X Bluetooth stack in libdiveceomputer? How about Android? And (here's hoping) IOS? If we want to have support for this platforms, probably the best choice will be to use the Qt Bluetooth API and let the framework to deal with the differences between the platforms. Because of this I believe that it is a good idea for libdivecomputer to let the application to open its custom communication implementation or to be able to pass callbacks for basic read/write operations. So we agree that this is a reasonable way to do things. And then on the Subsurface side we use QtBluetooth plus a Windows specific Bluetooth implementation. Correct? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On 2015-06-14 23:43, Claudiu Olteanu wrote: Thanks for your suggestions, Jef! I can definitely do that but I was looking for a solution which doesn't imply changes on *libdivecomputer* project. An ideal solution which is implemented on *Subsurface* project and doesn't need to re-implement the dive computer communication protocol. You can't do that. They are mutually exclusive. Libdivecomputer's internals are not exposed to application. That's by design. So if you want to implement the downloading entirely in Subsurface, without touching libdivecomputer, then you'll have to re-implement the dive computer protocol too. If you want to re-use that part, you'll have to modify libdivecomputer. Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
Hi, As you can see I am having some troubles and I don't know in which direction to go. If we want to implement the data transfer using the Qt Bluetooth API, then we should find a way to integrate it with the implementation of the serial port communication from *libDC* project. If this is not possible and we still want to use the Qt Bluetooth API, then we need to do some specific implementation for each dive computer vendor. This implies a lot of useless work since it is already implemented in *libDC* project. I already tested the *serial_write* and *serial_read* methods from *libDC*, using the *QtBluetoothSocket* descriptor and they work. These are the basic methods used to communicate with the device in *libDC*. The only problem is that I need to call somehow the initialization method to initialize the *vtable* of the device which stores functions pointers to some device specific implementation for read/write methods. As I said, the initialization is done in the *open* method and I don't know how to fake its call. I cannot manually initialize the *vtable* because the methods are declared static. If I find a way to initialize the *vtable* and to replace the serial port descriptor with my socket descriptor, then I expect things to work. Do you have any suggestions how to do that? Do you believe that this is a bad idea? Should I give up with the Qt Bluetooth API and move further? Thanks, Claudiu On Sun, Jun 14, 2015 at 12:43 AM, Claudiu Olteanu olteanu.vasilica.clau...@gmail.com wrote: Hi there, This week I did some research about the *libdivecomputer* parser and its serial port implementation. I find out that each device has a virtual table which contains information about the device's family (*type*), a fingerprint and references to some operations (read/write/dump/close) needed for the serial communication. This table is initialized when the device is opened. In order to create a parser you need to provide the following information: - the device type (find out in the *vtable* or in our *descriptorLookup* map) - some device information (the *model*, the *serial* and the *firmware*) read from the device - some information about device's clock (*systime* and *devtime*) read from the device Therefore all needed information can be obtained and we can create and use the *libdivecomputer* parser. The problem is that the devices expose only the Serial Port Profile and we can communicate with them only using the virtual COM port. Each device family has its own specific implementation and it requires a lot of work. Since the serial communication is already implemented in libdivecomputer I tried to find a way to use it along with the Qt Bluetooth API functionalities. I thought that if somehow I will replace the file descriptor of device's serial port from libdc with the socket descriptor obtained using the Qt Bluetooth API it should work. I am not sure if this is a good or a bad one. I didn't find a solution to do that anyway. We need to open the device in order to initialize its *vtable* and it will fail when it will try to open the serial port, since there is no port to open. I also tried to create a named pipe, to use it to simulate the virtual COM port and to pass its name to devname field from *device_data_t* structure (used when the port is opened). I didn't even believe that it would work but I said that I should give it a try. Apparently the *dc_device_open* method fails when it tries to call the *ioctl* or the *tcgetattr* method. I simulated the calls and both fail with an *Inappropriate ioctl* error. This is probably due the fact that it uses the TIOCEXCL command which is specific for terminals. Then I though that maybe a *pseudo-tty* can solve my problem, but I didn't have time to research. Do you believe that a pty could be a solution? Besides that I did some research about *QtSerialPort* and *QtSerialDevice* in order to see if I can emulate the virtual port and use it in my scenario. Unfortunately I didn't find anything useful. Now I am a little stuck and I don't know if I should give up with the Qt Bluetooth API and move further. Should I start to look over Jef's work and to finish his implementation? Another possible solution could be to implement the *bind* command from *rfcomm* tool. I looked over the implementation and I can do that with a simple *ioctl* call. I will use the Qt Bluetooth API for scanning, pairing and collecting information about remote devices. When the client wants to connect to the device, then I will create a RFCOMM device and use it in the *downloadfromdivecomputer* implementation. The inconvenient is that in order to create a RFCOMM device we need root privileges. Please let me know if you have other ideas or if I should concentrate my work in other direction. Best wishes, Claudiu ___ subsurface mailing list
Re: [GSoC] Week 3 (Native Bluetooth support)
No; I thought I explained this before we started... libdivecomputer has two reasonably distinct parts. The communication with the dive computer and the parsing of the data that was downloaded from the dive computer. My goal is to do the communication with Bluetooth based dive computers from within Subsurface and then pass the data buffers to libdivecomputer for parsing. My concern is related to the fact that I have to communicate with the device using the Serial Port Profile and there is not a standard protocol for the communication. As you know, each member has its own implementation. Each vendor expects its own specific commands through the virtual COM port of the device. Because this is already implemented in *libdivecomputer*, I thought that it will be easier if I will find a way to integrate it. I don't think that's the right way to go. Of course, we have our own branch of *libdivecomputer* and we could always make changes, but that would move us further and further away from upstream which is the opposite of what I'd want I don't intend to make changes in *libdivecomputer* branch. I want to find a way to initialize the *vtable* from Subsurface by faking the call of *dc_device_open* and return it with success. Then I want to change the *fd* from the serial port with my socket descriptor. As I said, I am not sure if it is possible or if it will work, but it will simplify my work. I think you should consider just using the parser from libdivecomputer and doing the downloading entirely in Subsurface. Ok. Then I will implement the data transfer for HW OSTC family and try to use the *hw_ostc_parser* parser to interpret the data. If all works well, I will start to implement the communication for other families or I will go further with the implementation for Windows. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
Thanks for your suggestions, Jef! I can definitely do that but I was looking for a solution which doesn't imply changes on *libdivecomputer* project. An ideal solution which is implemented on *Subsurface* project and doesn't need to re-implement the dive computer communication protocol. Although I am not sure if it is possible... Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On 14-06-15 21:56, Dirk Hohndel wrote: On Jun 14, 2015, at 12:00 PM, Claudiu Olteanu Do you have any suggestions how to do that? Do you believe that this is a bad idea? Should I give up with the Qt Bluetooth API and move further? I think you should consider just using the parser from libdivecomputer and doing the downloading entirely in Subsurface. A quick and dirty intermediate solution might be to re-implement the serial interface using the Qt bluetooth api, and then compile that one instead of libdivecomputer's own serial code. Of course this is not something we can use immediately, but it does give Claudiu an opportunity to get familiar with all the bluetooth stuf without having to re-implement any dive computer communication protocol. Another alternative is something like I did in my bluetooth prototype: pick one dive computer backend (for the test device Claudiu has) and #ifdef all serial_*() calls to replace them with the bluetooth ones. Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On Mon, Jun 15, 2015 at 12:22:36AM +0300, Claudiu Olteanu wrote: No; I thought I explained this before we started... libdivecomputer has two reasonably distinct parts. The communication with the dive computer and the parsing of the data that was downloaded from the dive computer. My goal is to do the communication with Bluetooth based dive computers from within Subsurface and then pass the data buffers to libdivecomputer for parsing. My concern is related to the fact that I have to communicate with the device using the Serial Port Profile and there is not a standard protocol for the communication. As you know, each member has its own implementation. Each vendor expects its own specific commands through the virtual COM port of the device. Because this is already implemented in *libdivecomputer*, I thought that it will be easier if I will find a way to integrate it. Gotcha. Yes, you are of course correct. My mistake. I don't think that's the right way to go. Of course, we have our own branch of *libdivecomputer* and we could always make changes, but that would move us further and further away from upstream which is the opposite of what I'd want I don't intend to make changes in *libdivecomputer* branch. I want to find a way to initialize the *vtable* from Subsurface by faking the call of *dc_device_open* and return it with success. Then I want to change the *fd* from the serial port with my socket descriptor. As I said, I am not sure if it is possible or if it will work, but it will simplify my work. Cool I think you should consider just using the parser from libdivecomputer and doing the downloading entirely in Subsurface. Ok. Then I will implement the data transfer for HW OSTC family and try to use the *hw_ostc_parser* parser to interpret the data. If all works well, I will start to implement the communication for other families or I will go further with the implementation for Windows. That sounds like a good plan /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
On Jun 14, 2015, at 12:00 PM, Claudiu Olteanu olteanu.vasilica.clau...@gmail.com wrote: Hi, As you can see I am having some troubles and I don't know in which direction to go. If we want to implement the data transfer using the Qt Bluetooth API, then we should find a way to integrate it with the implementation of the serial port communication from libDC project. If this is not possible and we still want to use the Qt Bluetooth API, then we need to do some specific implementation for each dive computer vendor. This implies a lot of useless work since it is already implemented in libDC project. No; I thought I explained this before we started... libdivecomputer has two reasonably distinct parts. The communication with the dive computer and the parsing of the data that was downloaded from the dive computer. My goal is to do the communication with Bluetooth based dive computers from within Subsurface and then pass the data buffers to libdivecomputer for parsing. I already tested the serial_write and serial_read methods from libDC, using the QtBluetoothSocket descriptor and they work. These are the basic methods used to communicate with the device in libDC. The only problem is that I need to call somehow the initialization method to initialize the vtable of the device which stores functions pointers to some device specific implementation for read/write methods. As I said, the initialization is done in the open method and I don't know how to fake its call. I cannot manually initialize the vtable because the methods are declared static. I don't think that's the right way to go. Of course, we have our own branch of libdivecomputer and we could always make changes, but that would move us further and further away from upstream which is the opposite of what I'd want If I find a way to initialize the vtable and to replace the serial port descriptor with my socket descriptor, then I expect things to work. Do you have any suggestions how to do that? Do you believe that this is a bad idea? Should I give up with the Qt Bluetooth API and move further? I think you should consider just using the parser from libdivecomputer and doing the downloading entirely in Subsurface. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
