On 16 December, 2019 - Brendan Horan wrote:
----- On 16 Dec, 2019, at 9:41 PM, Anton Lundin glance@acc.umu.se wrote:
We produce some terribly bad error messages, Like:
"Unable to open /dev/ttyS31 Suunto (EON Steel)" even when we're trying to open the hid device first. We shouldn't try the serial port anyway, and not include it in the error message. This is a quite old and annoying bug, in subsurface.
This is what made me ask the original question around the tty device. Also my lack of understanding about the fact the watch is a HID device too.
Brendan: Could you try to run subsurface from the command line, and seeing what it says there?
I start the Subsurface appImage from the command line, this is the output I get.
$ /opt/bin/subsurface -v Subsurface v4.9.3, built with libdivecomputer v0.7.0-devel-Subsurface-NG (ce6d9896a79afaa82641132e338f8744714c8593) built with Qt Version 5.12.4, runtime from Qt Version 5.12.4 built with libgit2 0.26.0 "validateGL(): created OpenGLContext." "validateGL(): obtained QOpenGLFunctions." "validateGL(): detected OpenGL version 3.0." loading dive data from ("/home/brendan/.subsurface/brendan.xml")
File locations:
Unable to get local git directory Cloud URL: No valid cloud credentials set.
Image filename table: /home/brendan/.subsurface/hashes Local picture directory: /home/brendan/.subsurface/picturedata/
Starting download from /dev/ttyUSB0 downloading only new dives [0.008240] ERROR: Failed to claim the usb interface (LIBUSB_ERROR_BUSY). [in ../../src/usbhid.c:604 (dc_usbhid_open)] Finishing download thread: "Unable to open /dev/ttyUSB0 Suunto (D5)"
That is it. Unless you need me to run Subsurface in a different way? I can also go back to the libdivecomputer test tool directly after this and still get a successful connection.
So, the real error we hit here is that LIBUSB_ERROR_BUSY . We try to open the device but we get a error as answer.
Why does subsurface get a LIBUSB_ERROR_BUSY, when dctool can open the device just fine, thats the question.
The appimages libdivecomputer is build directly against libusb, is your local build against hidapi ?
You can check with `grep -i hid config.h` in your libdivecomputer build tree.
//Anton