The OP doesn't mention what hardware they have, which makes this hard to
say much about, but it looks like it's mixing two different use cases.
For "real" USB Garmins, as opposed to serial Garmins attached via a
USB/Serial adapters, there are basically two different models for using
Garmins with GPSBabel on Linux.
1) There is a Linux kernel module that grabs the USB interface, does "USB
Garmin stuff", and then presents the device as /dev/ttyUSBwhatever to any
apps that spoke the Garmin serial protocol. This was neat for
compatibility, but this driver never actually worked very well. (Sorry.)
To use this, you'd load the kernel module and then use serial driver name
in the -f argument.
2) Let GPSBabel (almost) speak directly with the USB hardware. GPSBabel
communicates via libusb directly to the hardware and is cognizant of all
the (many, many) Garmin USB quirks and models. To use this, we'd use the
name "usb" instead of a /dev node. usb:-1 would list device names and
usb:0 or usb:1 or whatever would handle the extremely uncommon case (unless
you were me) of having multiple USB Garmins.
The problem with #1 is that it didn't actually work very well and didn't
benefit from the wide exposure to Garmin hardware that GPSBabel natively
did. In particular, it had problems with tracks and routes, IIRC. It also
"hogged" the device and made it impossible for our libusb layer (the "-f
usb:" stuff) to actually speak the device. This problem was so common that
for a long time, we special cased the error message:
fatal("usb_set_configuration failed, probably because kernel driver '%s'\n
is blocking our access to the USB device.\n"
"For more information see https://www.gpsbabel.org/os/Linux_Hotplug.html\n";,
drvnm);
The code still peeks through at
https://github.com/GPSBabel/gpsbabel/blob/master/jeeps/gpslibusb.cc
Suggestion: mark this as closed. the error message was improved and the
fixes were deliver a long, long time ago. No devices using Garmin comm
protocol (current ones mount as mass storage devices and you basically copy
GPX files to/from them) since about 2008 or so. The libusb path is so
inconsequential it's being strongly considered for removal upstream because
of disuse and churn at the libusb api level.
Please close this issue.
