<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>