Hi all,
From my understanding the Suunto D5 is supported via bluetooth. This commit seems to support that. https://github.com/libdivecomputer/libdivecomputer/commit/0dc10062ced1be6091...
However I do not think the D5 is supported via USB connectivity? The only kernel messages I see are : -------------------------- hid-generic 0003:1493:0035.0012: hiddev97,hidraw4: USB HID v1.01 Device [Suunto GURU3] on usb-0000:03:00.0-2/input0 -------------------------- I don't get a /dev/tty$$$ device node either. Is this a libdivecomputer limitation or the USB interface may not be supported in the Linux kernel? I also may not have enabled kernel support for the USB device, unsure what it actually is yet. Thank you, Brendan
On 14/12/2019 09:24, Brendan Horan wrote:
From my understanding the Suunto D5 is supported via bluetooth. This commit seems to support that. https://github.com/libdivecomputer/libdivecomputer/commit/0dc10062ced1be6091...
However I do not think the D5 is supported via USB connectivity? The only kernel messages I see are : -------------------------- hid-generic 0003:1493:0035.0012: hiddev97,hidraw4: USB HID v1.01 Device [Suunto GURU3] on usb-0000:03:00.0-2/input0 -------------------------- I don't get a /dev/tty$$$ device node either.
Is this a libdivecomputer limitation or the USB interface may not be supported in the Linux kernel? I also may not have enabled kernel support for the USB device, unsure what it actually is yet.
The Suunto D5 uses USB HID instead of usb-serial. That's why you don't see a /dev/tty device node. It's not needed for USB HID communication. Libdivecomputer will talk to the USB device directly with either libusb or hidapi. Of course libdivecomputer needs to be compiled with one of those libraries enabled, and your kernel needs to have USB HID enabled as well. You may also need an udev rule to get permission to access the device: https://github.com/libdivecomputer/libdivecomputer/blob/master/contrib/udev/... The commit you refer to also added the USB VID/PID (1493/0035) of the Suunto D5. Jef
----- On 14 Dec, 2019, at 10:07 PM, Jef Driesen jef@libdivecomputer.org wrote:
The Suunto D5 uses USB HID instead of usb-serial. That's why you don't see a /dev/tty device node. It's not needed for USB HID communication. Libdivecomputer will talk to the USB device directly with either libusb or hidapi. Of course libdivecomputer needs to be compiled with one of those libraries enabled, and your kernel needs to have USB HID enabled as well.
Pretty sure HID is working fine in my kernel. I use the app image for Subsurface. Unsure how that is compiled.
You may also need an udev rule to get permission to access the device:
https://github.com/libdivecomputer/libdivecomputer/blob/master/contrib/udev/...
I've set that up now. I am still getting issues when using Subsurface. Device node looks correct, owner/group and permissions match the rule. How would I be able to test this via a local hand compiled libdivecomputer / test applications? Thanks for your time, Brendan
On 15/12/2019 09:02, Brendan Horan wrote:
----- On 14 Dec, 2019, at 10:07 PM, Jef Driesen jef@libdivecomputer.org wrote:
The Suunto D5 uses USB HID instead of usb-serial. That's why you don't see a /dev/tty device node. It's not needed for USB HID communication. Libdivecomputer will talk to the USB device directly with either libusb or hidapi. Of course libdivecomputer needs to be compiled with one of those libraries enabled, and your kernel needs to have USB HID enabled as well.
Pretty sure HID is working fine in my kernel. I use the app image for Subsurface. Unsure how that is compiled.
I don't know whether usb hid is enabled in the appimage or not. Or whether the appimage can access usb hid devices.
You may also need an udev rule to get permission to access the device:
https://github.com/libdivecomputer/libdivecomputer/blob/master/contrib/udev/...
I've set that up now. I am still getting issues when using Subsurface. Device node looks correct, owner/group and permissions match the rule.
How would I be able to test this via a local hand compiled libdivecomputer / test applications?
You can use the dctool command-line tool, which is part of the libdivecomputer source code. It's located in the examples subdirectory. Download with these options: ./dctool -vv -l dctool.log -f eonsteel download -o dctool.xml -t usbhid Jef
On December 15, 2019 8:37:52 AM PST, Jef Driesen <jef@libdivecomputer.org> wrote:
On 15/12/2019 09:02, Brendan Horan wrote:
I don't know whether usb hid is enabled in the appimage or not. Or whether the appimage can access usb hid devices.
It should be enabled, I'm traveling and can't test this right now. If you can access the dive computer with the tool Jef mentions I'll need to go back and figure out why the AppImage doesn't see your dive computer /D -- From my phone
On 15 December, 2019 - Dirk Hohndel wrote:
On December 15, 2019 8:37:52 AM PST, Jef Driesen <jef@libdivecomputer.org> wrote:
On 15/12/2019 09:02, Brendan Horan wrote:
I don't know whether usb hid is enabled in the appimage or not. Or whether the appimage can access usb hid devices.
It should be enabled, I'm traveling and can't test this right now.
If you can access the dive computer with the tool Jef mentions I'll need to go back and figure out why the AppImage doesn't see your dive computer
Now when azure is back on its feet again, I re-ran the github-action to produce a appimage from master, and then I can test this. I don't have a hid-talking dive computer around, but other hid devices which is enough to test that subsurface can talk to them. I'll come back when I have some answers... //Anton -- Anton Lundin +46702-161604
On 16 December, 2019 - Anton Lundin wrote:
On 15 December, 2019 - Dirk Hohndel wrote:
On December 15, 2019 8:37:52 AM PST, Jef Driesen <jef@libdivecomputer.org> wrote:
On 15/12/2019 09:02, Brendan Horan wrote:
I don't know whether usb hid is enabled in the appimage or not. Or whether the appimage can access usb hid devices.
It should be enabled, I'm traveling and can't test this right now.
If you can access the dive computer with the tool Jef mentions I'll need to go back and figure out why the AppImage doesn't see your dive computer
Now when azure is back on its feet again, I re-ran the github-action to produce a appimage from master, and then I can test this.
I don't have a hid-talking dive computer around, but other hid devices which is enough to test that subsurface can talk to them.
I'll come back when I have some answers...
Some pesky checksums came in my way, but it seems that we're trying to open the devices just as we should. 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. Brendan: Could you try to run subsurface from the command line, and seeing what it says there? //Anton -- Anton Lundin +46702-161604
----- 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. Thanks for every ones time, Brendan
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 -- Anton Lundin +46702-161604
----- On 16 Dec, 2019, at 10:16 PM, Anton Lundin glance@acc.umu.se wrote:
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.
Now this gets interesting. I think I am using libusb : /t/libdivecomputer (master|…) $ grep -i hid config.h /* hidapi library */ /* #undef HAVE_HIDAPI */ /t/libdivecomputer (master|…) $ grep -i usb config.h /* libusb library */ #define HAVE_LIBUSB 1 /t/libdivecomputer (master|…) $
On 2019-12-16 14:27, Brendan Horan wrote:
----- On 16 Dec, 2019, at 10:16 PM, Anton Lundin glance@acc.umu.se wrote:
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.
Now this gets interesting. I think I am using libusb :
/t/libdivecomputer (master|…) $ grep -i hid config.h /* hidapi library */ /* #undef HAVE_HIDAPI */ /t/libdivecomputer (master|…) $ grep -i usb config.h /* libusb library */ #define HAVE_LIBUSB 1
That's normal. On Linux, libusb is currently the default because hidapi is just a wrapper around libusb. Jef
----- On 16 Dec, 2019, at 10:51 PM, Jef Driesen jef@libdivecomputer.org wrote:
That's normal. On Linux, libusb is currently the default because hidapi is just a wrapper around libusb.
Jef
Thanks! Not sure where to proceed here. I am fairly certain this is not a libdivecomputer bug. Should I log a bug/start a mailing list topic on Subsurface ? Happy to help out where I can, just not sure where right now. Thanks brendan
On 18 December, 2019 - Brendan Horan wrote:
----- On 16 Dec, 2019, at 10:51 PM, Jef Driesen jef@libdivecomputer.org wrote:
That's normal. On Linux, libusb is currently the default because hidapi is just a wrapper around libusb.
Jef
Thanks!
Not sure where to proceed here. I am fairly certain this is not a libdivecomputer bug. Should I log a bug/start a mailing list topic on Subsurface ?
Happy to help out where I can, just not sure where right now.
Something causes LIBUSB_ERROR_BUSY You could always try to ltrace/strace/systrace subsurface when trying to download to try to figure out the answer. The easiest way is probably that you build yourself a copy of subsurface from source with debug symbols and just single step into that code trying to figure out whats happening there. //Anton -- Anton Lundin +46702-161604
On 2019-12-18 15:41, Anton Lundin wrote:
On 18 December, 2019 - Brendan Horan wrote:
Not sure where to proceed here. I am fairly certain this is not a libdivecomputer bug. Should I log a bug/start a mailing list topic on Subsurface ?
Happy to help out where I can, just not sure where right now.
Something causes LIBUSB_ERROR_BUSY
Usually this indicates another program or driver has already claimed the interface. But in that case, I would expect to get the same error from dctool. But apparently that's not the case. Maybe there is something different in how an appimages run, compared to a "native" application? For example some kind of sandboxing, or other security restrictions? Note that the LIBUSB_ERROR_BUSY is returned by libusb_claim_interface(). That means the USB device enumeration, and opening the device worked in the appimage.
You could always try to ltrace/strace/systrace subsurface when trying to download to try to figure out the answer.
The easiest way is probably that you build yourself a copy of subsurface from source with debug symbols and just single step into that code trying to figure out whats happening there.
Building subsurface with debug symbols is probably not going to help much, because the error is returned somewhere from inside libusb. You can instead enable debug output from libusb, by setting an environment variable: export LIBUSB_DEBUG=4 /opt/bin/subsurface -v Jef
----- On 19 Dec, 2019, at 3:17 PM, Jef Driesen jef@libdivecomputer.org wrote:
Building subsurface with debug symbols is probably not going to help much, because the error is returned somewhere from inside libusb. You can instead enable debug output from libusb, by setting an environment variable:
export LIBUSB_DEBUG=4 /opt/bin/subsurface -v
Thanks for that information, and sorry for the delayed response. Here is what I get when I run Subsurface using the above commands: ~ $ export LIBUSB_DEBUG=4 ~ $ /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 [timestamp] [threadID] facility level [function call] <message> -------------------------------------------------------------------------------- [ 0.000015] [00000d2c] libusb: debug [libusb_init] created default context [ 0.000098] [00000d2c] libusb: debug [libusb_init] libusb v1.0.21.11156 [ 0.000200] [00000d2c] libusb: debug [find_usbfs_path] found usbfs at /dev/bus/usb [ 0.000240] [00000d2c] libusb: debug [op_init] bulk continuation flag supported [ 0.000285] [00000d2c] libusb: debug [op_init] zero length packet flag supported [ 0.000333] [00000d2c] libusb: debug [op_init] sysfs can relate devices [ 0.000349] [00000d2c] libusb: debug [op_init] sysfs has complete descriptors [ 0.000944] [00000d2d] libusb: debug [linux_udev_event_thread_main] udev event thread entering. [ 0.004443] [00000d2c] libusb: debug [linux_get_device_address] getting address for device: usb1 detached: 0 [ 0.004456] [00000d2c] libusb: debug [linux_get_device_address] scan usb1 [ 0.004501] [00000d2c] libusb: debug [linux_get_device_address] bus=1 dev=1 [ 0.004508] [00000d2c] libusb: debug [linux_enumerate_device] busnum 1 devaddr 1 session_id 257 [ 0.004512] [00000d2c] libusb: debug [linux_enumerate_device] allocating new device for 1/1 (session 257) [ 0.004622] [00000d2c] libusb: debug [linux_get_device_address] getting address for device: 1-1 detached: 0 [ 0.004629] [00000d2c] libusb: debug [linux_get_device_address] scan 1-1 [ 0.004664] [00000d2c] libusb: debug [linux_get_device_address] bus=1 dev=6 [ 0.004670] [00000d2c] libusb: debug [linux_enumerate_device] busnum 1 devaddr 6 session_id 262 [ 0.004675] [00000d2c] libusb: debug [linux_enumerate_device] allocating new device for 1/6 (session 262) [ 0.004719] [00000d2c] libusb: debug [linux_get_parent_info] Dev 0x7f02440229d0 (1-1) has parent 0x7f0244022580 (usb1) port 1 [ 0.004780] [00000d2c] libusb: debug [linux_get_device_address] getting address for device: 1-8 detached: 0 [ 0.004785] [00000d2c] libusb: debug [linux_get_device_address] scan 1-8 [ 0.004816] [00000d2c] libusb: debug [linux_get_device_address] bus=1 dev=4 [ 0.004822] [00000d2c] libusb: debug [linux_enumerate_device] busnum 1 devaddr 4 session_id 260 [ 0.004827] [00000d2c] libusb: debug [linux_enumerate_device] allocating new device for 1/4 (session 260) [ 0.004858] [00000d2c] libusb: debug [linux_get_parent_info] Dev 0x7f0244022ae0 (1-8) has parent 0x7f0244022580 (usb1) port 8 [ 0.004918] [00000d2c] libusb: debug [linux_get_device_address] getting address for device: 1-9 detached: 0 [ 0.004922] [00000d2c] libusb: debug [linux_get_device_address] scan 1-9 [ 0.004948] [00000d2c] libusb: debug [linux_get_device_address] bus=1 dev=5 [ 0.004951] [00000d2c] libusb: debug [linux_enumerate_device] busnum 1 devaddr 5 session_id 261 [ 0.004956] [00000d2c] libusb: debug [linux_enumerate_device] allocating new device for 1/5 (session 261) [ 0.004981] [00000d2c] libusb: debug [linux_get_parent_info] Dev 0x7f0244022bf0 (1-9) has parent 0x7f0244022580 (usb1) port 9 [ 0.005029] [00000d2c] libusb: debug [linux_get_device_address] getting address for device: usb2 detached: 0 [ 0.005032] [00000d2c] libusb: debug [linux_get_device_address] scan usb2 [ 0.005059] [00000d2c] libusb: debug [linux_get_device_address] bus=2 dev=1 [ 0.005062] [00000d2c] libusb: debug [linux_enumerate_device] busnum 2 devaddr 1 session_id 513 [ 0.005066] [00000d2c] libusb: debug [linux_enumerate_device] allocating new device for 2/1 (session 513) [ 0.005160] [00000d2c] libusb: debug [usbi_add_pollfd] add fd 25 events 1 [ 0.005174] [00000d2c] libusb: debug [usbi_io_init] using timerfd for timeouts [ 0.005178] [00000d2c] libusb: debug [usbi_add_pollfd] add fd 27 events 1 [ 0.005185] [00000d2c] libusb: debug [libusb_get_device_list] [ 0.005203] [00000d2c] libusb: debug [libusb_get_device_descriptor] [ 0.005207] [00000d2c] libusb: debug [libusb_get_device_descriptor] [ 0.005210] [00000d2c] libusb: debug [libusb_get_device_descriptor] [ 0.005214] [00000d2c] libusb: debug [libusb_get_device_descriptor] [ 0.005245] [00000d2c] libusb: debug [libusb_open] open 1.6 [ 0.005274] [00000d2c] libusb: debug [usbi_add_pollfd] add fd 28 events 4 [ 0.005279] [00000d2c] libusb: debug [libusb_claim_interface] interface 0 [0.005390] ERROR: Failed to claim the usb interface (LIBUSB_ERROR_BUSY). [in ../../src/usbhid.c:604 (dc_usbhid_open)] [ 0.005299] [00000d2c] libusb: debug [libusb_close] [ 0.005304] [00000d2c] libusb: debug [usbi_remove_pollfd] remove fd 28 [ 0.005316] [00000d2c] libusb: debug [libusb_exit] [ 0.005320] [00000d2c] libusb: debug [libusb_exit] destroying default context [ 0.005329] [00000d2c] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.005334] [00000d2c] libusb: debug [handle_events] poll fds modified, reallocating [ 0.005340] [00000d2c] libusb: debug [handle_events] poll() 2 fds with timeout in 0ms [ 0.005346] [00000d2c] libusb: debug [handle_events] poll() returned 0 [ 0.005350] [00000d2c] libusb: debug [libusb_unref_device] destroy device 2.1 [ 0.005353] [00000d2c] libusb: debug [libusb_unref_device] destroy device 1.5 [ 0.005358] [00000d2c] libusb: debug [libusb_unref_device] destroy device 1.4 [ 0.005362] [00000d2c] libusb: debug [libusb_unref_device] destroy device 1.6 [ 0.005366] [00000d2c] libusb: debug [libusb_unref_device] destroy device 1.1 [ 0.005370] [00000d2c] libusb: debug [usbi_remove_pollfd] remove fd 25 [ 0.005382] [00000d2c] libusb: debug [usbi_remove_pollfd] remove fd 27 [ 0.005400] [00000d2d] libusb: debug [linux_udev_event_thread_main] udev event thread exiting Finishing download thread: "Unable to open /dev/ttyUSB0 Suunto (D5)" ~ $
On 2019-12-30 13:59, Brendan Horan wrote:
[ 0.005245] [00000d2c] libusb: debug [libusb_open] open 1.6 [ 0.005274] [00000d2c] libusb: debug [usbi_add_pollfd] add fd 28 events 4 [ 0.005279] [00000d2c] libusb: debug [libusb_claim_interface] interface 0 [0.005390] ERROR: Failed to claim the usb interface (LIBUSB_ERROR_BUSY). [in ../../src/usbhid.c:604 (dc_usbhid_open)] [ 0.005299] [00000d2c] libusb: debug [libusb_close] [ 0.005304] [00000d2c] libusb: debug [usbi_remove_pollfd] remove fd 28 [ 0.005316] [00000d2c] libusb: debug [libusb_exit]
I'm afraid this didn't give much more info. It looks like the underlying ioctl syscall: ioctl(fd, IOCTL_USBFS_CLAIMINTF, &iface); failed with EBUSY, and that's about it. There is no clue why it failed. Jef
On Mon, Jan 6, 2020 at 6:02 AM Jef Driesen <jef@libdivecomputer.org> wrote:
I'm afraid this didn't give much more info. It looks like the underlying ioctl syscall:
ioctl(fd, IOCTL_USBFS_CLAIMINTF, &iface);
Ugh, they have their own names for it. The kernel calls it USBDEVFS_CLAIMINTERFACE.
failed with EBUSY, and that's about it. There is no clue why it failed.
That just means that somebody else already claimed it. Either some kernel driver, or (in this case much more likely) another usbfs user. I wonder what would happen if libdivecomputer would just try to use the thing regardless. Because maybe the reason it's busy is that it already got claimed by the Android "associate app with usb device" logic? Linus
On 06 January, 2020 - Linus Torvalds wrote:
On Mon, Jan 6, 2020 at 6:02 AM Jef Driesen <jef@libdivecomputer.org> wrote:
I'm afraid this didn't give much more info. It looks like the underlying ioctl syscall:
ioctl(fd, IOCTL_USBFS_CLAIMINTF, &iface);
Ugh, they have their own names for it. The kernel calls it USBDEVFS_CLAIMINTERFACE.
failed with EBUSY, and that's about it. There is no clue why it failed.
That just means that somebody else already claimed it. Either some kernel driver, or (in this case much more likely) another usbfs user.
I wonder what would happen if libdivecomputer would just try to use the thing regardless.
Because maybe the reason it's busy is that it already got claimed by the Android "associate app with usb device" logic?
I don't think it's a "android" app, It's a appimage. Is it some selinux profile which kicks in when the appimage is run from /opt ( or /tmp/ where the appimage gets mounted)? Have you tried to build subsurface from source? Or maybe just copy the appdir to the same place as your dctool which works and test that? //Anton -- Anton Lundin +46702-161604
On Mon, Jan 6, 2020 at 1:48 PM Anton Lundin <glance@acc.umu.se> wrote:
I don't think it's a "android" app, It's a appimage.
Bah, I obviously didn't read things carefully enough.
Is it some selinux profile which kicks in when the appimage is run from /opt ( or /tmp/ where the appimage gets mounted)?
Hmm. I don't see where the kernel could care, but yeah, maybe there's some interaction with the appimage mounting its own usbdev filesystem etc. I'm not seeing why/how it would claim all interfaces, but I wonder if this also has some interaction with libusb_set_auto_detach_kernel_driver(), which should mean that claiming the interface releases it from the default HID driver. I'm not seeing any sign of that in the debug messages. But I don't really know libusb. .. goes off and looks .. Oh, it should mean that it actually uses IOCTL_USBFS_DISCONNECT_CLAIM (aka USBDEVFS_DISCONNECT_CLAIM). That has a few other EBUSY return cases, but I'm not seeing where that would matter either. Linus
----- On 7 Jan, 2020, at 5:48 AM, glance glance@acc.umu.se wrote:
Have you tried to build subsurface from source? Or maybe just copy the appdir to the same place as your dctool which works and test that?
No I have not. I will go read up the Install doc to get a better understanding on building it. Are there any debug options/flags that may help me debug this? Compile time options or such. Thanks for your time, Brendan
----- On 8 Jan, 2020, at 8:55 AM, brendanhoran brendanhoran@basstech.net wrote:
No I have not. I will go read up the Install doc to get a better understanding on building it. Are there any debug options/flags that may help me debug this? Compile time options or such.
So I went off and compiled Subsurface via the instructions in the INSTALL file. I was then able to connect my D5 and everything worked as expected. So there has to be something strange with the app image version. I have been using the app image version for well over a year now. With a different dive computer (also USB) with out any issue what so ever. Not sure where I should log this bug now? Thanks for everyones time, Brendan Full log for anyone interested (with LIBUSB_DEBUG=4 exported) : $ ./subsurface -v Subsurface v4.9.3-755-gde846bad96e5, built with libdivecomputer v0.7.0-devel-Subsurface-NG (4eb34b1466e7dff3ee2c0dfbeeef3642c2166d8c) built with Qt Version 5.13.2, runtime from Qt Version 5.13.2 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 all dives [timestamp] [threadID] facility level [function call] <message> -------------------------------------------------------------------------------- [ 0.000016] [000095bf] libusb: debug [libusb_init] created default context [ 0.000102] [000095bf] libusb: debug [libusb_init] libusb v1.0.21.11156 [ 0.000218] [000095bf] libusb: debug [find_usbfs_path] found usbfs at /dev/bus/usb [ 0.000280] [000095bf] libusb: debug [op_init] bulk continuation flag supported [ 0.000308] [000095bf] libusb: debug [op_init] zero length packet flag supported [ 0.000371] [000095bf] libusb: debug [op_init] sysfs can relate devices [ 0.000391] [000095bf] libusb: debug [op_init] sysfs has complete descriptors [ 0.000848] [000095c0] libusb: debug [linux_udev_event_thread_main] udev event thread entering. [ 0.004491] [000095bf] libusb: debug [linux_get_device_address] getting address for device: usb1 detached: 0 [ 0.004521] [000095bf] libusb: debug [linux_get_device_address] scan usb1 [ 0.004659] [000095bf] libusb: debug [linux_get_device_address] bus=1 dev=1 [ 0.004677] [000095bf] libusb: debug [linux_enumerate_device] busnum 1 devaddr 1 session_id 257 [ 0.004694] [000095bf] libusb: debug [linux_enumerate_device] allocating new device for 1/1 (session 257) [ 0.004962] [000095bf] libusb: debug [linux_get_device_address] getting address for device: 1-2 detached: 0 [ 0.004977] [000095bf] libusb: debug [linux_get_device_address] scan 1-2 [ 0.005033] [000095bf] libusb: debug [linux_get_device_address] bus=1 dev=6 [ 0.005042] [000095bf] libusb: debug [linux_enumerate_device] busnum 1 devaddr 6 session_id 262 [ 0.005052] [000095bf] libusb: debug [linux_enumerate_device] allocating new device for 1/6 (session 262) [ 0.005142] [000095bf] libusb: debug [linux_get_parent_info] Dev 0x7f31400222c0 (1-2) has parent 0x7f31400223c0 (usb1) port 2 [ 0.005288] [000095bf] libusb: debug [linux_get_device_address] getting address for device: 1-8 detached: 0 [ 0.005300] [000095bf] libusb: debug [linux_get_device_address] scan 1-8 [ 0.005353] [000095bf] libusb: debug [linux_get_device_address] bus=1 dev=4 [ 0.005363] [000095bf] libusb: debug [linux_enumerate_device] busnum 1 devaddr 4 session_id 260 [ 0.005372] [000095bf] libusb: debug [linux_enumerate_device] allocating new device for 1/4 (session 260) [ 0.005426] [000095bf] libusb: debug [linux_get_parent_info] Dev 0x7f3140022db0 (1-8) has parent 0x7f31400223c0 (usb1) port 8 [ 0.005569] [000095bf] libusb: debug [linux_get_device_address] getting address for device: 1-9 detached: 0 [ 0.005580] [000095bf] libusb: debug [linux_get_device_address] scan 1-9 [ 0.005633] [000095bf] libusb: debug [linux_get_device_address] bus=1 dev=5 [ 0.005642] [000095bf] libusb: debug [linux_enumerate_device] busnum 1 devaddr 5 session_id 261 [ 0.005652] [000095bf] libusb: debug [linux_enumerate_device] allocating new device for 1/5 (session 261) [ 0.005711] [000095bf] libusb: debug [linux_get_parent_info] Dev 0x7f3140022ec0 (1-9) has parent 0x7f31400223c0 (usb1) port 9 [ 0.005850] [000095bf] libusb: debug [linux_get_device_address] getting address for device: usb2 detached: 0 [ 0.005862] [000095bf] libusb: debug [linux_get_device_address] scan usb2 [ 0.005920] [000095bf] libusb: debug [linux_get_device_address] bus=2 dev=1 [ 0.005931] [000095bf] libusb: debug [linux_enumerate_device] busnum 2 devaddr 1 session_id 513 [ 0.005941] [000095bf] libusb: debug [linux_enumerate_device] allocating new device for 2/1 (session 513) [ 0.006163] [000095bf] libusb: debug [usbi_add_pollfd] add fd 20 events 1 [ 0.006206] [000095bf] libusb: debug [usbi_io_init] using timerfd for timeouts [ 0.006218] [000095bf] libusb: debug [usbi_add_pollfd] add fd 22 events 1 [ 0.006233] [000095bf] libusb: debug [libusb_get_device_list] [ 0.006282] [000095bf] libusb: debug [libusb_get_device_descriptor] [ 0.006302] [000095bf] libusb: debug [libusb_get_device_descriptor] [ 0.006315] [000095bf] libusb: debug [libusb_get_device_descriptor] [ 0.006329] [000095bf] libusb: debug [libusb_get_device_descriptor] [ 0.006453] [000095bf] libusb: debug [libusb_open] open 1.6 [ 0.006507] [000095bf] libusb: debug [usbi_add_pollfd] add fd 23 events 4 [ 0.006528] [000095bf] libusb: debug [libusb_claim_interface] interface 0 [ 0.010462] [000095bf] libusb: debug [libusb_alloc_transfer] transfer 0x7f314001d060 [ 0.010505] [000095bf] libusb: debug [libusb_submit_transfer] transfer 0x7f314001d060 [ 0.010530] [000095bf] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 64 [ 0.010590] [000095bf] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.010613] [000095bf] libusb: debug [handle_events] poll fds modified, reallocating [ 0.010638] [000095bf] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms [ 0.018564] [000095bf] libusb: debug [handle_events] poll() returned 1 [ 0.018617] [000095bf] libusb: debug [reap_for_handle] urb type=1 status=0 transferred=64 [ 0.018639] [000095bf] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1 [ 0.018654] [000095bf] libusb: debug [handle_bulk_completion] last URB in transfer --> complete! [ 0.018700] [000095bf] libusb: debug [usbi_handle_transfer_completion] transfer 0x7f314001d060 has callback 0x7f316c512460 [ 0.018718] [000095bf] libusb: debug [sync_transfer_cb] actual_length=64 [ 0.018755] [000095bf] libusb: debug [libusb_free_transfer] transfer 0x7f314001d060 [ 0.018780] [000095bf] libusb: debug [libusb_alloc_transfer] transfer 0x7f3140021cf0 [ 0.018793] [000095bf] libusb: debug [libusb_submit_transfer] transfer 0x7f3140021cf0 [ 0.018806] [000095bf] libusb: debug [add_to_flying_list] arm timerfd for timeout in 5000ms (first in line) [ 0.018842] [000095bf] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 64 [ 0.018884] [000095bf] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.018900] [000095bf] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms [ 0.030550] [000095bf] libusb: debug [handle_events] poll() returned 1 [ 0.030600] [000095bf] libusb: debug [reap_for_handle] urb type=1 status=0 transferred=64 [ 0.030647] [000095bf] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1 [ 0.030667] [000095bf] libusb: debug [handle_bulk_completion] last URB in transfer --> complete! [ 0.030685] [000095bf] libusb: debug [disarm_timerfd] [ 0.030706] [000095bf] libusb: debug [usbi_handle_transfer_completion] transfer 0x7f3140021cf0 has callback 0x7f316c512460 [ 0.030724] [000095bf] libusb: debug [sync_transfer_cb] actual_length=64 [ 0.030746] [000095bf] libusb: debug [libusb_free_transfer] transfer 0x7f3140021cf0 INFO: dc_device_open error value of 0 [ 0.030859] [000095bf] libusb: debug [libusb_alloc_transfer] transfer 0x7f3140021dd0 [ 0.030880] [000095bf] libusb: debug [libusb_submit_transfer] transfer 0x7f3140021dd0 [ 0.030898] [000095bf] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 64 [ 0.030943] [000095bf] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.030960] [000095bf] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms [ 0.031549] [000095bf] libusb: debug [handle_events] poll() returned 1 [ 0.031596] [000095bf] libusb: debug [reap_for_handle] urb type=1 status=0 transferred=64 [ 0.031615] [000095bf] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1 [ 0.031634] [000095bf] libusb: debug [handle_bulk_completion] last URB in transfer --> complete! [ 0.031653] [000095bf] libusb: debug [usbi_handle_transfer_completion] transfer 0x7f3140021dd0 has callback 0x7f316c512460 [ 0.031671] [000095bf] libusb: debug [sync_transfer_cb] actual_length=64 [ 0.031693] [000095bf] libusb: debug [libusb_free_transfer] transfer 0x7f3140021dd0 [ 0.031716] [000095bf] libusb: debug [libusb_alloc_transfer] transfer 0x7f314001ed40 [ 0.031731] [000095bf] libusb: debug [libusb_submit_transfer] transfer 0x7f314001ed40 [ 0.031748] [000095bf] libusb: debug [add_to_flying_list] arm timerfd for timeout in 5000ms (first in line) [ 0.031773] [000095bf] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 64 [ 0.031810] [000095bf] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.031827] [000095bf] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms [ 0.036541] [000095bf] libusb: debug [handle_events] poll() returned 1 [ 0.036579] [000095bf] libusb: debug [reap_for_handle] urb type=1 status=0 transferred=64 [ 0.036596] [000095bf] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1 [ 0.036612] [000095bf] libusb: debug [handle_bulk_completion] last URB in transfer --> complete! [ 0.036624] [000095bf] libusb: debug [disarm_timerfd] [ 0.036638] [000095bf] libusb: debug [usbi_handle_transfer_completion] transfer 0x7f314001ed40 has callback 0x7f316c512460 [ 0.036650] [000095bf] libusb: debug [sync_transfer_cb] actual_length=64 [ 0.036664] [000095bf] libusb: debug [libusb_free_transfer] transfer 0x7f314001ed40 [ 0.036687] [000095bf] libusb: debug [libusb_alloc_transfer] transfer 0x7f314001ee20 [ 0.036700] [000095bf] libusb: debug [libusb_submit_transfer] transfer 0x7f314001ee20 [ 0.036712] [000095bf] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 64 [ 0.036754] [000095bf] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.036769] [000095bf] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms [ 0.037592] [000095bf] libusb: debug [handle_events] poll() returned 1 [ 0.037632] [000095bf] libusb: debug [reap_for_handle] urb type=1 status=0 transferred=64 [ 0.037643] [000095bf] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1 [ 0.037654] [000095bf] libusb: debug [handle_bulk_completion] last URB in transfer --> complete! [ 0.037665] [000095bf] libusb: debug [usbi_handle_transfer_completion] transfer 0x7f314001ee20 has callback 0x7f316c512460 [ 0.037675] [000095bf] libusb: debug [sync_transfer_cb] actual_length=64 [ 0.037688] [000095bf] libusb: debug [libusb_free_transfer] transfer 0x7f314001ee20 [ 0.037705] [000095bf] libusb: debug [libusb_alloc_transfer] transfer 0x7f314001b2c0 [ 0.037714] [000095bf] libusb: debug [libusb_submit_transfer] transfer 0x7f314001b2c0 [ 0.037723] [000095bf] libusb: debug [add_to_flying_list] arm timerfd for timeout in 5000ms (first in line) [ 0.037740] [000095bf] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 64 [ 0.037771] [000095bf] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.037781] [000095bf] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms [ 0.038557] [000095bf] libusb: debug [handle_events] poll() returned 1 [ 0.038597] [000095bf] libusb: debug [reap_for_handle] urb type=1 status=0 transferred=64 [ 0.038605] [000095bf] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1 [ 0.038613] [000095bf] libusb: debug [handle_bulk_completion] last URB in transfer --> complete! [ 0.038622] [000095bf] libusb: debug [disarm_timerfd] [ 0.038632] [000095bf] libusb: debug [usbi_handle_transfer_completion] transfer 0x7f314001b2c0 has callback 0x7f316c512460 [ 0.038640] [000095bf] libusb: debug [sync_transfer_cb] actual_length=64 [ 0.038651] [000095bf] libusb: debug [libusb_free_transfer] transfer 0x7f314001b2c0 [ 0.038667] [000095bf] libusb: debug [libusb_alloc_transfer] transfer 0x7f314001b3a0 [ 0.038675] [000095bf] libusb: debug [libusb_submit_transfer] transfer 0x7f314001b3a0 [ 0.038683] [000095bf] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 64 [ 0.038706] [000095bf] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.038714] [000095bf] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms [ 0.039524] [000095bf] libusb: debug [handle_events] poll() returned 1 [ 0.039545] [000095bf] libusb: debug [reap_for_handle] urb type=1 status=0 transferred=64 [ 0.039552] [000095bf] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1 [ 0.039559] [000095bf] libusb: debug [handle_bulk_completion] last URB in transfer --> complete! [ 0.039565] [000095bf] libusb: debug [usbi_handle_transfer_completion] transfer 0x7f314001b3a0 has callback 0x7f316c512460 [ 0.039572] [000095bf] libusb: debug [sync_transfer_cb] actual_length=64 [ 0.039580] [000095bf] libusb: debug [libusb_free_transfer] transfer 0x7f314001b3a0 [ 0.039590] [000095bf] libusb: debug [libusb_alloc_transfer] transfer 0x7f314001b3a0 [ 0.039596] [000095bf] libusb: debug [libusb_submit_transfer] transfer 0x7f314001b3a0 [ 0.039602] [000095bf] libusb: debug [add_to_flying_list] arm timerfd for timeout in 5000ms (first in line) [ 0.039612] [000095bf] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 64 [ 0.039628] [000095bf] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.039634] [000095bf] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms [ 0.040554] [000095bf] libusb: debug [handle_events] poll() returned 1 [ 0.040573] [000095bf] libusb: debug [reap_for_handle] urb type=1 status=0 transferred=64 [ 0.040583] [000095bf] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1 [ 0.040591] [000095bf] libusb: debug [handle_bulk_completion] last URB in transfer --> complete! [ 0.040600] [000095bf] libusb: debug [disarm_timerfd] [ 0.040609] [000095bf] libusb: debug [usbi_handle_transfer_completion] transfer 0x7f314001b3a0 has callback 0x7f316c512460 [ 0.040618] [000095bf] libusb: debug [sync_transfer_cb] actual_length=64 [ 0.040633] [000095bf] libusb: debug [libusb_free_transfer] transfer 0x7f314001b3a0 [ 0.040667] [000095bf] libusb: debug [libusb_release_interface] interface 0 [ 0.041464] [000095bf] libusb: debug [libusb_close] [ 0.041486] [000095bf] libusb: debug [usbi_remove_pollfd] remove fd 23 [ 0.041500] [000095bf] libusb: debug [libusb_exit] [ 0.041504] [000095bf] libusb: debug [libusb_exit] destroying default context [ 0.041513] [000095bf] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.041517] [000095bf] libusb: debug [handle_events] poll fds modified, reallocating [ 0.041530] [000095bf] libusb: debug [handle_events] poll() 2 fds with timeout in 0ms [ 0.041542] [000095bf] libusb: debug [handle_events] poll() returned 0 [ 0.041550] [000095bf] libusb: debug [libusb_unref_device] destroy device 2.1 [ 0.041557] [000095bf] libusb: debug [libusb_unref_device] destroy device 1.5 [ 0.041564] [000095bf] libusb: debug [libusb_unref_device] destroy device 1.4 [ 0.041570] [000095bf] libusb: debug [libusb_unref_device] destroy device 1.6 [ 0.041576] [000095bf] libusb: debug [libusb_unref_device] destroy device 1.1 [ 0.041583] [000095bf] libusb: debug [usbi_remove_pollfd] remove fd 20 [ 0.041605] [000095bf] libusb: debug [usbi_remove_pollfd] remove fd 22 [ 0.041647] [000095c0] libusb: debug [linux_udev_event_thread_main] udev event thread exiting Finishing download thread: 0 dives downloaded
----- On 16 Dec, 2019, at 12:37 AM, Jef Driesen jef@libdivecomputer.org wrote:
You can use the dctool command-line tool, which is part of the libdivecomputer source code. It's located in the examples subdirectory.
Download with these options:
./dctool -vv -l dctool.log -f eonsteel download -o dctool.xml -t usbhid
That seems to work just fine (This computer has no dives ) : /t/l/examples (master|…) $ ./dctool -vv -l dctool.log -f eonsteel download -o dctool.xml -t usbhid DATETIME 2019-12-16T13:57:17Z (1576504637) VERSION 0.7.0-devel (ae733fd8a82f2c6f331a869325ac7428dad30851) Opening the I/O stream (usbhid, null). INFO: Open: vid=1493, pid=0035 INFO: Open: interface=0, endpoints=82,02 Opening the device (Suunto EON Steel). INFO: Timeout: value=5000 INFO: Write: size=64, data=3F1000000100000000000400000002002A007AA09C30000000000000000000000000000000000000000000000000000000000000000000000000000000000000 DEBUG: cmd: size=16, data=00000100000000000400000002002A00 INFO: Read: size=64, data=3F3C000202002DF40000300000004755525533000000000000000000000031393434313030303432343800000000020070064406000002007006000400000000 DEBUG: rcv: size=60, data=000202002DF4000030000000475552553300000000000000000000003139343431303030343234380000000002007006440600000200700600040000 Registering the event handler. Registering the cancellation handler. Downloading the dives. Event: model=0 (0x00000000), firmware=33583110 (0x02007006), serial=1136475928 (0x43bd3f18) INFO: Write: size=64, data=3F19100805002DF401000D00000000000000303A2F6469766573004864B5E8000000000000000000000000000000000000000000000000000000000000000000 DEBUG: cmd: size=25, data=100805002DF401000D00000000000000303A2F646976657300 INFO: Read: size=64, data=3F0C10080A002DF40100000000004755525533000000000000000000000031393434313030303432343800000000020070064406000002007006000400000000 DEBUG: rcv: size=12, data=10080A002DF4010000000000 DEBUG: DIR_LOOKUP: size=0, data= INFO: Write: size=64, data=3F0C100905002DF40200000000001416235500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 DEBUG: cmd: size=12, data=100905002DF4020000000000 INFO: Read: size=64, data=3F1410090A002DF40200080000000000000001000000000000000000000031393434313030303432343800000000020070064406000002007006000400000000 DEBUG: rcv: size=20, data=10090A002DF40200080000000000000001000000 DEBUG: dir packet: size=8, data=0000000001000000 INFO: Write: size=64, data=3F0C100A05002DF4030000000000B0A39D0700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 DEBUG: cmd: size=12, data=100A05002DF4030000000000 INFO: Read: size=64, data=3F0C100A0A002DF40300000000000000000001000000000000000000000031393434313030303432343800000000020070064406000002007006000400000000 DEBUG: rcv: size=12, data=100A0A002DF4030000000000
participants (5)
-
Anton Lundin -
Brendan Horan -
Dirk Hohndel -
Jef Driesen -
Linus Torvalds