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