Yes.
You didn't indicate version or OS, so I will guess here. In your
hotplug scripts directory (/lib/udev on Ubuntu), you should find one or
more scripts with "gpsd" in the file names. Remove them or move them
aside.
> and then ask gpsd to test given device addresses one by one (ie,
> /dev/ttyUSB0, /dev/ttyUSB1, and so on) through my application?
Not directly. But a bit of scripting using gpsdctl (assuming a recent
version of gpsd, say since June, 2011) and gpsdlogger should give you
a way to do that. See the gpsd hotplug script(s) for ideas.
Recent versions with gpsdctl are much easier to work with. If you
aren't using a version with gpsdctl, consider upgrading to one.
I have no idea what your application does, so this is a guess. Perhaps
have your application test the devices, and have it launch gpsd on the
appropriate one.
--
Thanks for the reply. I tried to use gpsdctl, but I ran into an issue when removing a device (ie, gpsdctl remove /dev/ttyUSBx): The device gets removed from gpsd's pool, but I can no longer access the serial port the device belongs to until I physically reconnect the device. I tried this on two devices... one that uses a Prolific chipset (is an actual GPS), and another that uses an FTDI chipset (is not a GPS). The FTDI chipset is the one that causes the problem. However, using both simple serial port code (C/C++) and a gui based serial port comm/monitor (cutecom), I can connect, talk to and disconnect to either device as many times as I want (before gpsd tries to identify the FTDI device -- once that happens, the port in question is locked, or "busy" until I physically reconnect... even killing gpsd doesn't relinquish the port). Is this a bug? I'm using gpsd 3.3 on Arch Linux, on an x86 machine.