Welcome, ladies and gentlemen, to another darkly humorous tale of the seamy side of GPS interfacing. GPSD working with USB GPS mice has, when properly installed, lovely plug-and-play self-configuring behavior. That is, you plug a USB GPS into a USB port, the hotplug system notifies the gpsd daemon that the GPS is available, the daemon records this fact…and subsequently when you start up any GPSD client application It Just Works. Well, usually. There’s a dangerous weakness in the machinery, and yesterday it came around and bit us in the ass.
The root of the problem is a hole in the the USB standard. For most other kinds of USB devices (printers, mice, mass storage, smart cards, hubs, what have you) there’s a defined device class code which gets presented to your USB subsystem; so, for example, your print spooler can enumerate all the USB printers attached to your system and ignore everything that isn’t a printer. But the standard does not define a device class code for GPSes.
If there were a GPS device class, and GPS manufacturers followed the standard, then GPSD’s hotplug rules could simply say “hand everything with that type to GPSD” and all would be happiness. But there’s no such class, so we have to whitelist a bunch of vendor/product IDs and assume that if the device presents one on this list, it’s a GPS.
In truth, we’d probably have to do this even if there were a GPS device class. You see, all the GPS mice we’ve ever seen are are lash-ups consisting of a receiver module that’s wedded by a sort of bastardized TTL version of RS-232 with an RS-232-to-USB adapter chip. The USB device class is presented down the wire to your PC by the adapter chip, which would have to be custom-modified to show something other than its own device class and vendor/product ID. These devices are produced on such thin margins that the vendors might not spend the extra pennies for the customization.
In point of fact, USB to serial adapters don’t have their own USB class either (they return 0xFF for “Vendor Specific”). So we have to whitelist the vendor/product ID pairs of the USB adapter chips most commonly used in GPS mice; by far the most common of these, incidentally, is a doohickey called the Pacific Logic 2303.
So here we are with our udev rules file that’s watching for a plugin event from anything on the whitelist. The udev rule calls a Python script written by yours truly which launches a gpsd instance if one is not already running, then stuffs a notification up the daemon’s special control socket that said device might be a GPS. Later, when a GPSD client app wants location data, the daemon will actually open every device on its stash list and attempt to recognize GPS information flooding from them (not a trivial process; the GPS information could arrive in any of 13 mutually incompatible formats, which are untangled from each other by a big honkin’ state machine also written by yours truly).
Astute readers will already see the problem. We don’t actually have any guarantee that the thing behind any given whitelisted adapter is, in fact, a GPS. But for six years this failure case remained theoretical. Until yesterday.
Yesterday, we got a plaintive bug report from a guy who was trying to mate a cute little Linux SBC called a Gumstix with a GSM modem. A perfectly reasonable thing to do if you were, say, trying to remote-control some kind of instrumentation package over a GSM cell network. Our guy complained that every time he plugged in one of his modems, gpsd would spam a bunch of data at it. This sometimes gave the modem indigestion.
Well, guess what? Both of the USB-to-serial adapters he tried using with his GSM modem were in our whitelist, and gpsd duly sent them the crapload of vendor-specific probe strings it uses to try to prod a GPS into returning an identifying response. So our friend tried removing the GPSD package from the Gumstix, only to find that the KDE environment depends on it. FAIL.
The workaround is to uninstall GPSD’s udev rules. But now he’s going to have to peg GPSD’s version, or his modems will fall down go boom again right after his next upgrade pulls a new GPSD package installation and installs a new copy of our udev rules.
This basically sucks all around. And there’s no good fix. And if there were one, the skeezy Pacific-Rim fly-by-nights who pump out the world’s production of GPS mice probably wouldn’t apply it. Sigh…another wonderful day in the life of GPSD.
UPDATE: The person who reported the bug says I misunderstood his use case, though apparently not in an essential way. You can read his description.
UPDATE2: Ah, seems I conflated two bug reports from different people, one of which really did involve a Gumstix.