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