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 [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
