[GSoC] Week 3 (Native Bluetooth support)

[Dirk Hohndel]

> On Jun 14, 2015, at 12:00 PM, Claudiu Olteanu <olteanu.vasilica.claudiu at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150614/81312478/attachment.html>