<div dir="ltr"><div><div>Hi,</div><div><br></div><div>As you can see I am having some troubles and I don't </div><div>know in which direction to go. If we want to implement </div><div>the data transfer using the Qt Bluetooth API, then we </div><div>should find a way to integrate it with the implementation </div><div>of the serial port communication from <i>libDC</i> project.</div><div><br></div><div>If this is not possible and we still want to use the </div><div>Qt Bluetooth API, then we need to do some specific </div><div>implementation for each dive computer vendor. </div><div>This implies a lot of useless work since it is already </div><div>implemented in <i>libDC</i> project.</div><div><br></div><div>I already tested the <b>serial_write</b> and <b>serial_read</b> methods </div><div>from <i>libDC</i>, using the <i>QtBluetoothSocket</i> descriptor and </div><div>they work. These are the basic methods used to </div><div>communicate with the device in <i>libDC</i>. </div><div><br></div><div>The only problem is that I need to call somehow the</div><div>initialization method to initialize the <i>vtable</i> of the </div><div>device which stores functions pointers to some device </div><div>specific implementation for read/write methods.</div><div>As I said, the initialization is done in the <b>open</b> method </div><div>and I don't know how to fake its call. I cannot manually </div><div>initialize the <i>vtable</i> because the methods are declared </div><div>static.</div><div><br></div><div>If I find a way to initialize the <i>vtable</i> and to replace </div><div>the serial port descriptor with my socket descriptor, then</div><div>I expect things to work.</div><div><br></div><div>Do you have any suggestions how to do that? Do you </div><div>believe that this is a bad idea? Should I give up with the </div><div>Qt Bluetooth API and move further?</div><div><br></div><div>Thanks,</div><div>Claudiu</div></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 14, 2015 at 12:43 AM, Claudiu Olteanu <span dir="ltr"><<a href="mailto:olteanu.vasilica.claudiu@gmail.com" target="_blank">olteanu.vasilica.claudiu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi there,<br></div><div><br></div><div>This week I did some research about the <b>libdivecomputer</b> </div><div>parser and its serial port implementation.</div><div><br></div><div>I find out that each device has a virtual table which </div><div>contains information about the device's family (<i>type</i>), </div><div>a fingerprint and references to some operations </div><div>(read/write/dump/close) needed for the serial </div><div>communication. This table is initialized when the device </div><div>is opened.</div><div><br></div><div>In order to create a parser you need to provide the </div><div>following information:</div><div>- the device type (find out in the <i>vtable</i> or in our </div><div> <i>descriptorLookup</i> map)</div><div>- some device information (the <i>model</i>, the <i>serial</i> and </div><div> the <i>firmware</i>) read from the device</div><div>- some information about device's clock (<i>systime</i> and </div><div> <i>devtime</i>) read from the device</div><div><br></div><div>Therefore all needed information can be obtained and we </div><div>can create and use the <b>libdivecomputer</b> parser.</div><div><br></div><div>The problem is that the devices expose only the Serial </div><div>Port Profile and we can communicate with them only using </div><div>the virtual COM port. Each device family has its own </div><div>specific implementation and it requires a lot of work. </div><div><br></div><div>Since the serial communication is already implemented in </div><div>libdivecomputer I tried to find a way to use it along with </div><div>the Qt Bluetooth API functionalities. I thought that if </div><div>somehow I will replace the file descriptor of device's </div><div>serial port from libdc with the socket descriptor obtained </div><div>using the Qt Bluetooth API it should work. I am not sure </div><div>if this is a good or a bad one. I didn't find a solution </div><div>to do that anyway. We need to open the device in order to </div><div>initialize its <i>vtable</i> and it will fail when it will try </div><div>to open the serial port, since there is no port to open.</div><div><br></div><div>I also tried to create a named pipe, to use it to simulate </div><div>the virtual COM port and to pass its name to devname field </div><div>from <i>device_data_t</i> structure (used when the port is opened). </div><div>I didn't even believe that it would work but I said that I </div><div>should give it a try. Apparently the <i>dc_device_open</i> method </div><div>fails when it tries to call the <i>ioctl</i> or the <i>tcgetattr</i> </div><div>method. I simulated the calls and both fail with an </div><div>"<i>Inappropriate ioctl</i>" error. This is probably due the fact </div><div>that it uses the TIOCEXCL command which is specific for </div><div>terminals.</div><div><br></div><div>Then I though that maybe a <i>pseudo-tty</i> can solve my problem,</div><div>but I didn't have time to research. Do you believe that</div><div>a pty could be a solution?</div><div><br></div><div>Besides that I did some research about <i>QtSerialPort</i> and </div><div><i>QtSerialDevice</i> in order to see if I can emulate the virtual</div><div>port and use it in my scenario. Unfortunately I didn't </div><div>find anything useful.</div><div><br></div><div>Now I am a little stuck and I don't know if I should give </div><div>up with the Qt Bluetooth API and move further. Should I </div><div>start to look over Jef's work and to finish his </div><div>implementation?</div><div><br></div><div>Another possible solution could be to implement the <i>bind</i> </div><div>command from <b>rfcomm</b> tool. I looked over the implementation </div><div>and I can do that with a simple <i>ioctl</i> call. I will use the </div><div>Qt Bluetooth API for scanning, pairing and collecting </div><div>information about remote devices. When the client wants </div><div>to connect to the device, then I will create a RFCOMM </div><div>device and use it in the <i>downloadfromdivecomputer</i> </div><div>implementation. The inconvenient is that in order to </div><div>create a RFCOMM device we need root privileges.</div><div><br></div><div>Please let me know if you have other ideas or if I </div><div>should concentrate my work in other direction.</div><div><br></div><div>Best wishes,</div><div>Claudiu</div></div>
</blockquote></div><br></div>